[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Taler] taler-exchange scalability update

From: Christian Grothoff
Subject: [Taler] taler-exchange scalability update
Date: Mon, 6 Sep 2021 12:21:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

Dear all,

I just finished the benchmarks on the taler-exchange-transfer tool, the
last one which needed to have sharding implemented.

Executive summary

taler-exchange-transfer now supports sharding. Single-system
performance of the subsystem was measured around 62k
transactions/second. Rough subsystem summary:

- taler-exchange-wirewatch : 50k TPS
- taler-exchange-httpd     :  1k TPS (*)
- taler-exchange-aggregator: 33k TPS (I/O bound)
- taler-exchange-transfer  : 62k TPS

(*): CPU-bound on single-system, should scale nicely with more CPU power

Experiments and results

Using taler-aggregator-benchmark and taler-exchange-aggregator, I
populated a database with 1 M deposits to 1 M different merchants (1
deposit/merchant). The baseline for this system, so running the transfer
logic on it without sharding takes 167s. That is roughly 5988 initiated
wire transfers/second. Using 32k shards and a pool of 8 threads for the
'fakebank', I get:

 4 workers: 45s = 22k trans/sec
 8 workers: 25s = 40k trans/sec
16 workers: 18s = 55k trans/sec

Using the largest possible shards -- 62500 (which is exactly 1
shard/worker) time improves to 16s or 62k trans/sec.  I would
expect slightly higher rates if the workload in the database was larger
(1M records is getting small for this) and with more cores. However, the
main bottleneck now is probably that we do an HTTP request for every
single transfer. Here, a REST API modification to allow the client to
send multiple transfers in one HTTP request would likely do wonders.
Alas, in that case the entire error reporting via HTTP status codes
would have to be redesigned as well as we'd to return the status of
individual transfers.

However, that would likely be a premature optimization, as
taler-exchange-transfer deals with outgoing wire transfers to merchants,
so the number of transactions taler-exchange-transfer needs to deal with
is MUCH lower than the number of payments, as presumably the same
merchant will be paid repeatedly via Taler and the aggregation logic
should thus be able to group multiple Taler (micro)payments into one
taler-exchange-transfer (macro!) payment.


50k TPS is likely more than enough for taler-exchange-transfer.

Happy hacking!


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]