View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005100 | Taler | merchant backend | public | 2017-06-29 19:18 | 2024-01-12 14:04 |
| Reporter | Christian Grothoff | Assigned To | Marcello Stanisci | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| 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. |
| 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 |
| 2019-12-20 19:12 | Christian Grothoff | Status | resolved => closed |
| 2024-01-12 14:04 | Christian Grothoff | Category | merchant backend API (C) => mechant backend |
| 2025-03-22 14:09 | Christian Grothoff | Category | mechant backend => merchant backend |
