2018-05-26 09:43 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0005100Talermerchant backend API (C)public2018-05-11 16:08
ReporterChristian Grothoff 
Assigned ToMarcello Stanisci 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusresolvedResolutionfixed 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product VersionSVN HEAD 
Target Version0.6Fixed in Version 
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 ]
+Relationships

-Notes

~0012323

Marcello Stanisci (manager)

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

~0012506

Christian Grothoff (manager)

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

~0012732

Marcello Stanisci (manager)

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

~0012796

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).

~0012922

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.

~0012923

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.

~0012924

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.

~0012925

Marcello Stanisci (manager)

Commit 435390e has the final version.
+Notes

-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
+Issue History