2019-01-23 22:47 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0005100Talermerchant backend API (C)public2018-06-12 09:00
ReporterChristian Grothoff 
Assigned ToMarcello Stanisci 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product VersionSVN HEAD 
Target Version0.6Fixed in Version0.6 
Summary0005100: taler-merchant-generate-payments expansion to cover /track/ APIs
DescriptionFor stress-testing, we should add a command-line option to have taler-merchant-generate-payments also stress-test the /track/-APIs.
TagsNo tags attached.
Attached Files

-Relationships Relation Graph ] Dependency Graph ]



Marcello Stanisci (manager)

Can you elaborate more on this? The payments generator does just payments, how/why could it deal with /track?


Christian Grothoff (manager)

Mostly it should just _call_ the /track APIs to generate the respective load (it can throw the results away).


Marcello Stanisci (manager)

Still not super convinced: why using this utility to stress-test /track and
not the usual merchant-lib test cases?


Christian Grothoff (manager)

We gain the ability to test the performance of the /track APIs as well.

Basically, I want to be able to see if the database scales for *all*
relevant operations. Imagine we have a missing index for some /track
operation. We could then see that if we

1) generate 1M payments
2) run 10k /track operations

and things are awfully slow. Then we can optimize (either for faster
payments or faster track or both). OTOH, if you only optimize for a
subset of possible operations, _removing_ the index for /track would be
beneficial as maintaining the index is costly.

Note that both are perfectly legitimate: you may have a merchant that
really doesn't care about /track and wants to optimize payments only!
So if we can have the payments generator create X payments and then Y
/track operations, some database administrators may tune for X=10M and
Y=0, and others for X=1M and Y=1M.

What is important to me is that the tool allows a comprehensive
performance assessment (and also a full feature test that can be run against a production DB setup, not just a unit test).


Marcello Stanisci (manager)

fyi: the payment generator uses the old interpreter style to run
its commands. Something suggests to switch to the new "traits-based"
style for it as well.


Marcello Stanisci (manager)

Basically, it will behave the same way as the test cases do, but
we should be able to pass those three parameters: (1) how many payments,
(2) how many /track operations, and (3) which database we want to be filled
up with generated data.


Marcello Stanisci (manager)

mm, maybe (3) is not needed, both exchange and merchant are supposed
to run against their ordinary config files, which will instruct them
about the right database to use.


Marcello Stanisci (manager)

Commit 435390e has the final version.

-Issue History
Date Modified Username Field Change
2017-06-29 19:18 Christian Grothoff New Issue
2017-06-29 19:18 Christian Grothoff Status new => assigned
2017-06-29 19:18 Christian Grothoff Assigned To => Marcello Stanisci
2017-07-10 13:07 Marcello Stanisci Note Added: 0012323
2017-10-23 10:40 Christian Grothoff Target Version => 0.6
2017-10-23 10:40 Christian Grothoff Note Added: 0012506
2018-01-05 10:26 Marcello Stanisci Note Added: 0012732
2018-01-18 10:39 Christian Grothoff Note Added: 0012796
2018-05-03 13:47 Marcello Stanisci Note Added: 0012922
2018-05-03 13:48 Marcello Stanisci Note Added: 0012923
2018-05-03 13:52 Marcello Stanisci Note Added: 0012924
2018-05-11 16:08 Marcello Stanisci Note Added: 0012925
2018-05-11 16:08 Marcello Stanisci Status assigned => resolved
2018-05-11 16:08 Marcello Stanisci Resolution open => fixed
2018-06-12 09:00 Christian Grothoff Fixed in Version => 0.6
+Issue History