View Issue Details

IDProjectCategoryView StatusLast Update
0005100Talermerchant backend API (C)public2018-06-12 09:00
ReporterChristian GrothoffAssigned ToMarcello Stanisci 
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
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.

Activities

Marcello Stanisci

2017-07-10 13:07

manager   ~0012323

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

Christian Grothoff

2017-10-23 10:40

manager   ~0012506

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

Marcello Stanisci

2018-01-05 10:26

manager   ~0012732

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

Christian Grothoff

2018-01-18 10:39

manager   ~0012796

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

2018-05-03 13:47

manager   ~0012922

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

2018-05-03 13:48

manager   ~0012923

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

2018-05-03 13:52

manager   ~0012924

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

2018-05-11 16:08

manager   ~0012925

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