View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005153 | Taler | obsolete component | public | 2017-10-18 15:34 | 2018-04-15 20:33 |
Reporter | Florian Dold | Assigned To | Marcello Stanisci | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | 0.3 | ||||
Target Version | 0.5 | Fixed in Version | 0.5 | ||
Summary | 0005153: loading public account history of exchange is slow and not paginated | ||||
Description | See https://bank.demo.taler.net/public-accounts/Exchange It's pretty slow (1.4 warm page load) from the Inria (wired) network. Probably an issue with indices (since we sort on date). Additionally we should consider paginating it. But with the little data we have in there right now, it shouldn't be that slow even on one page! | ||||
Tags | No tags attached. | ||||
|
is it 1.4 _seconds_? |
|
Yes, forgot the unit. It's 1.4 seconds, which indicates the problem is somewhere in the backend, since the my connection to tripwire is *really* good from within Inria. |
|
Could we simply be missing an index for the DB? |
|
baa520a..44f92cd adds indices to the bank's transaction by sender/receiver/date. Note that I could not test the patch, as somehow my Python is very unhappy with the simplemathcaptcha. Not resolving the bug as the pagination is not implemented. Still, would be good to know if this fixes the performance issue. |
|
(if the performance issue is fixed, pagination can be deferred, as far as I care past 1.0). |
|
In dac7bc9..c8f9b7a I've expanded testcases to measure the time taken by the "history query" and fail if this time is "too big". In order to make sure this testcase passes, I have allowed the single record to be returned in <1.7 millisecs; but most of the times 1.5 millisecs was sufficient. Today, for example, the Exchange history page has around 550 lines, which should take ~0.8 secs to retrieve, so we need almost the half of the time needed before. If you agree with the math, I guess we can close this bug. |
|
I agree that this shows the indexing was effective, but we probably _still_ should eventually implement the pagination (i.e. by default show only 100 records, and then have pages 2,3,4,5... at the bottom to "see more"). But, it means we can bump this to "later" and no longer RC for 0.5. |
|
Pagination added at commit c794683. There isn't any "make N transfers"-command which could be useful to test this new pagination feature, though. |
Date Modified | Username | Field | Change |
---|---|---|---|
2017-10-18 15:34 | Florian Dold | New Issue | |
2017-10-18 15:34 | Florian Dold | Status | new => assigned |
2017-10-18 15:34 | Florian Dold | Assigned To | => Marcello Stanisci |
2017-10-18 15:38 | Marcello Stanisci | Note Added: 0012495 | |
2017-10-18 15:40 | Florian Dold | Note Added: 0012496 | |
2017-10-20 22:58 | Christian Grothoff | Note Added: 0012499 | |
2017-11-04 18:20 | Christian Grothoff | Note Added: 0012555 | |
2017-11-04 18:20 | Christian Grothoff | Note Added: 0012556 | |
2017-12-01 18:56 | Marcello Stanisci | Note Added: 0012621 | |
2017-12-01 18:57 | Marcello Stanisci | Note Edited: 0012621 | |
2017-12-01 19:02 | Christian Grothoff | Note Added: 0012622 | |
2017-12-01 19:03 | Christian Grothoff | Target Version | 0.5 => 0.7.1 |
2018-01-16 13:39 | Marcello Stanisci | Note Added: 0012792 | |
2018-01-16 13:39 | Marcello Stanisci | Status | assigned => resolved |
2018-01-16 13:39 | Marcello Stanisci | Resolution | open => fixed |
2018-01-17 16:51 | Christian Grothoff | Fixed in Version | => 0.5 |
2018-01-17 16:51 | Christian Grothoff | Target Version | 0.7.1 => 0.5 |
2018-04-15 20:33 | Christian Grothoff | Status | resolved => closed |
2022-08-23 20:26 | Christian Grothoff | Category | bank (demonstrator) => py bank (demonstrator, obsolete) |
2023-12-03 01:23 | Christian Grothoff | Category | py bank (demonstrator, obsolete) => obsolete componet |
2023-12-11 20:08 | Florian Dold | Category | obsolete componet => obsolete component |