View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005100 | Taler | merchant backend | public | 2017-06-29 17:18 | 2024-01-12 13:04 |
| Reporter | Christian Grothoff | Assigned To | Marcello Stanisci | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| 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 17:18 | Christian Grothoff | New Issue | |
| 2017-06-29 17:18 | Christian Grothoff | Status | new => assigned |
| 2017-06-29 17:18 | Christian Grothoff | Assigned To | => Marcello Stanisci |
| 2017-07-10 11:07 | Marcello Stanisci | Note Added: 0012323 | |
| 2017-10-23 08:40 | Christian Grothoff | Target Version | => 0.6 |
| 2017-10-23 08:40 | Christian Grothoff | Note Added: 0012506 | |
| 2018-01-05 09:26 | Marcello Stanisci | Note Added: 0012732 | |
| 2018-01-18 09:39 | Christian Grothoff | Note Added: 0012796 | |
| 2018-05-03 11:47 | Marcello Stanisci | Note Added: 0012922 | |
| 2018-05-03 11:48 | Marcello Stanisci | Note Added: 0012923 | |
| 2018-05-03 11:52 | Marcello Stanisci | Note Added: 0012924 | |
| 2018-05-11 14:08 | Marcello Stanisci | Note Added: 0012925 | |
| 2018-05-11 14:08 | Marcello Stanisci | Status | assigned => informing |
| 2018-05-11 14:08 | Marcello Stanisci | Resolution | open => fixed |
| 2018-06-12 07:00 | Christian Grothoff | Fixed in Version | => 0.6 |
| 2019-12-20 18:12 | Christian Grothoff | Status | informing => closed |
| 2024-01-12 13:04 | Christian Grothoff | Category | merchant backend API (C) => mechant backend |
| 2025-03-22 13:09 | Christian Grothoff | Category | mechant backend => merchant backend |