events.action: opened
events.author: paweljakubas
events.text: # Issue Number
  
  <!-- Put here a reference to the issue this PR relates to and which requirements it tackles -->
  #1097 
  
  # Overview
  
  <!-- Detail in a few bullet points the work accomplished in this PR -->
  
  - [x] I have experimented with criterion ... and realized it uses clock inside. decided to adopt it due to small number of dependencies
  - [x] I have created two fixture wallets scenario as the starting point (could be one fixture and one empty - the minimum that is needed for fee estimation endpoint)
  - [x] I have measured latencies for all specified in U/S endpoints 
  
  # Comments
  
  <!-- Additional comments or screenshots to attach if any -->
  I have tried criterion but end up with simple clock (here Monotone measurement). Then, I found this blog entry that to-not-small extent supports my findings : 
  https://chrisdone.com/posts/measuring-duration-in-haskell/
   
  <!-- 
  Don't forget to:
  
   ✓ Self-review your changes to make sure nothing unexpected slipped through
   ✓ Assign yourself to the PR
   ✓ Assign one or several reviewer(s)
   ✓ Once created, link this PR to its corresponding ticket
   ✓ Assign the PR to a corresponding milestone
   ✓ Acknowledge any changes required to the Wiki
  -->
events.title: Measure latencies for two fixture wallets
events.type: issue
events.action: created
events.author: rvl
events.text: This is a good start.
  
  The important thing about Criterion is not so much how it measures time but that it repeats the benchmark to get an accurate result, and calculates the statistical distribution of results. If we only measure once, we don't get that information.
  
  If this benchmark is run as part of a test suite, then the results are going to be inaccurrate, because other test cases may be running at the same time. So it should be a separate benchmark program. Then it can be run independently without the results being skewed by other processes.
  
  In any case, I think we should be using the iohk-monitoring framework for these type of benchmarks. It was written specifically for this purpose. Log traces can have timestamps attached - so just run the tests and collect the timings from the logs.
events.type: comment
events.action: created
events.author: paweljakubas
events.text: bors try
events.type: comment
events.action: created
events.author: paweljakubas
events.text: @rvl I have followed the path we discussed privately. So defined high level `ServerLog`, relocated everything to `jormungandr/test/bench`, used here `traceinTVar` and aptly pattern matching (and clearing the tvar in between). And then relied on meta fragment of LogObject to get UTCTime. And it works. Just we need to do something like this : 
  ```
  $ stack bench cardano-wallet-jormungandr
  cardano-wallet-jormungandr> benchmarks  
  Running 1 benchmarks...                 
  Benchmark latency: RUNNING...           
  Latencies for two fixture wallets scenario
      listWallets        - 20.2 ms        
      getWallet          - 11.1 ms        
      getUTxOsStatistics - 1.9 ms         
      listAddresses      - 7.1 ms         
      listTransactions   - 2.5 ms         
      postTransactionFee - 1.7 ms         
      listStakePools     - 1.2 ms         
      getNetworkInfo     - 0.4 ms         
  Benchmark latency: FINISH
  ```
events.type: comment
events.action: created
events.author: paweljakubas
events.text: bors try
events.type: comment
events.action: created
events.author: paweljakubas
events.text: bors try
events.type: comment
events.action: created
events.author: paweljakubas
events.text: bors try-
events.type: comment
events.action: created
events.author: paweljakubas
events.text: bors try
events.type: comment
events.action: created
events.author: rvl
events.text: Also when we say "latency", we need to say latency of _what_. We are measuring wallet server API response time.
events.type: comment
events.action: created
events.author: paweljakubas
events.text: bors r+
events.type: comment
events.action: created
events.author: paweljakubas
events.text: bors r+
events.type: comment
data_with_bots.bot: ## try
  
  # Build failed
    * [buildkite/cardano-wallet](https://buildkite.com/input-output-hk/cardano-wallet/builds/4597)
data_with_bots.meta: This message directly preceded comment from bot *iohk-bors[bot]* by author *paweljakubas*:
data_with_bots.text: bors try
data_with_bots.bot: ## try
  
  # Build succeeded
    * [buildkite/cardano-wallet](https://buildkite.com/input-output-hk/cardano-wallet/builds/4604)
data_with_bots.meta: This message directly preceded comment from bot *iohk-bors[bot]* by author *paweljakubas*:
data_with_bots.text: bors try
data_with_bots.bot: # Build failed
    * [buildkite/cardano-wallet](https://buildkite.com/input-output-hk/cardano-wallet/builds/4616)
data_with_bots.meta: This message directly preceded comment from bot *iohk-bors[bot]* by author *paweljakubas*:
data_with_bots.text: bors r+
data_with_bots.bot: # Build succeeded
    * [buildkite/cardano-wallet](https://buildkite.com/input-output-hk/cardano-wallet/builds/4620)
data_with_bots.meta: This message directly preceded comment from bot *iohk-bors[bot]* by author *paweljakubas*:
data_with_bots.text: bors r+
data_without_bots.meta: This message directly preceded comment from bot *iohk-bors[bot]* by author *paweljakubas*:
data_without_bots.text: bors try
data_without_bots.meta: This message directly preceded comment from bot *iohk-bors[bot]* by author *paweljakubas*:
data_without_bots.text: bors try
data_without_bots.meta: This message directly preceded comment from bot *iohk-bors[bot]* by author *paweljakubas*:
data_without_bots.text: bors r+
data_without_bots.meta: This message directly preceded comment from bot *iohk-bors[bot]* by author *paweljakubas*:
data_without_bots.text: bors r+