Feat/web socket chain history provider

[iccicci]

Context

Lace performs a huge amount of HTTP calls.

Proposed Solution

Implemented event based ChainHistoryProvider.transactionsByAddresses and UtxoProvider.

The load tests demonstrate this back end implementation is able to sustain even an unexpected workload: 100 users simultaneously performing wallet restoration.

Follow some load test results.

1 user performing wallet restoration:

_operational...............: avg=251ms    min=251ms    med=251ms    max=251ms    p(90)=251ms    p(95)=251ms
_sync......................: avg=7.94s    min=7.94s    med=7.94s    max=7.94s    p(90)=7.94s    p(95)=7.94s
_transactions_per_wallet...: avg=203      min=203      med=203      max=203      p(90)=203      p(95)=203

2 users simultaneously performing wallet restoration:

_operational...............: avg=169.5ms  min=86ms     med=169.5ms  max=253ms    p(90)=236.3ms  p(95)=244.65ms
_sync......................: avg=10.63s   min=9.86s    med=10.63s   max=11.4s    p(90)=11.24s   p(95)=11.32s
_transactions_per_wallet...: avg=239      min=203      med=239      max=275      p(90)=267.8    p(95)=271.4

3 users simultaneously performing wallet restoration:

_operational...............: avg=101.66ms min=35ms     med=42ms    max=228ms    p(90)=190.8ms  p(95)=209.39ms
_sync......................: avg=13.63s   min=12.66s   med=13.63s  max=14.61s   p(90)=14.41s   p(95)=14.51s
_transactions_per_wallet...: avg=200      min=122      med=203     max=275      p(90)=260.6    p(95)=267.8

4 users simultaneously performing wallet restoration:

_operational...............: avg=62.5ms  min=16ms     med=38ms   max=158ms    p(90)=122.3ms  p(95)=140.14ms
_sync......................: avg=10.14s  min=9.11s    med=10.09s max=11.27s   p(90)=10.99s   p(95)=11.13s
_transactions_per_wallet...: avg=209.75  min=84       med=162.5  max=430      p(90)=361.9    p(95)=395.95

5 users simultaneously performing wallet restoration:

_operational...............: avg=294.6ms  min=255ms    med=287ms   max=360ms    p(90)=330.8ms  p(95)=345.4ms
_sync......................: avg=15.78s   min=14.79s   med=15.86s  max=16.9s    p(90)=16.71s   p(95)=16.81s
_transactions_per_wallet...: avg=215.2    min=84       med=203     max=430      p(90)=352.8    p(95)=391.4

10 users simultaneously performing wallet restoration:

_operational...............: avg=45.8ms  min=14ms     med=32.5ms  max=180ms    p(90)=60.29ms p(95)=120.14ms
_sync......................: avg=23.65s  min=22.24s   med=23.56s  max=25.01s   p(90)=24.76s  p(95)=24.89s
_transactions_per_wallet...: avg=221.5   min=76       med=192     max=430      p(90)=394     p(95)=412

20 users simultaneously performing wallet restoration:

_operational...............: avg=303.85ms min=293ms    med=300.5ms  max=325ms    p(90)=315.1ms  p(95)=316.45ms
_sync......................: avg=56.01s   min=54.68s   med=56.01s   max=57.27s   p(90)=57.01s   p(95)=57.03s
_transactions_per_wallet...: avg=264.45   min=75       med=191.5    max=1141     p(90)=400.3    p(95)=465.55

50 users simultaneously performing wallet restoration:

_operational...............: avg=31.94ms min=11ms     med=35ms    max=81ms    p(90)=44ms    p(95)=46.55ms
_sync......................: avg=2m5s    min=2m4s     med=2m5s    max=2m6s    p(90)=2m6s    p(95)=2m6s
_transactions_per_wallet...: avg=251.86  min=22       med=201     max=1141    p(90)=424.6   p(95)=505.85

Here is not relevant the time, but moreover that even under an insane workload the server is able to complete its job without timeout errors for the customers.

100 users simultaneously performing wallet restoration:

_operational...............: avg=283.58ms min=248ms    med=279ms    max=529ms    p(90)=293ms    p(95)=393.54ms
_sync......................: avg=4m25s    min=4m23s    med=4m25s    max=4m26s    p(90)=4m26s    p(95)=4m26s 
_transactions_per_wallet...: avg=278.65   min=22       med=222      max=1141     p(90)=516.2    p(95)=602.2

100 users with lots of transactions simultaneously performing wallet restoration:

_operational...............: avg=35.63ms min=11ms   med=33ms    max=232ms    p(90)=40.5ms  p(95)=85.29ms
_sync......................: avg=7m22s   min=7m20s  med=7m22s   max=7m24s    p(90)=7m23s   p(95)=7m23s
_transactions_per_wallet...: avg=642.17  min=160    med=599     max=1746     p(90)=1039.7  p(95)=1308

Important Changes Introduced

The DbSyncChainHistoryProvider and the DbSyncUtxoProvider perform almost the same actions about utxos but with some slight difference.

They were aligned to produce exactly the same data with two purposes:

1. simply for coherence
2. CardanoWsClient uses the same source for both the pseudo-providers implementations; this simplified a lot the comparison tests.