View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005100||Taler||merchant backend API (C)||public||2017-06-29 19:18||2018-06-12 09:00|
|Reporter||Christian Grothoff||Assigned To||Marcello Stanisci|
|Platform||i7||OS||Debian GNU/Linux||OS Version||squeeze|
|Product Version||SVN HEAD|
|Target Version||0.6||Fixed in Version||0.6|
|Summary||0005100: taler-merchant-generate-payments expansion to cover /track/ APIs|
|Description||For stress-testing, we should add a command-line option to have taler-merchant-generate-payments also stress-test the /track/-APIs.|
|Tags||No tags attached.|
||Can you elaborate more on this? The payments generator does just payments, how/why could it deal with /track?|
||Mostly it should just _call_ the /track APIs to generate the respective load (it can throw the results away).|
Still not super convinced: why using this utility to stress-test /track and
not the usual merchant-lib test cases?
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).
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.
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.
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.
||Commit 435390e has the final version.|
|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|