View Issue Details

IDProjectCategoryView StatusLast Update
0005153Talerpy bank (demonstrator, obsolete)public2018-04-15 20:33
ReporterFlorian Dold Assigned ToMarcello Stanisci  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version0.3 
Target Version0.5Fixed in Version0.5 
Summary0005153: loading public account history of exchange is slow and not paginated

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!
TagsNo tags attached.


Marcello Stanisci

2017-10-18 15:38

viewer   ~0012495

is it 1.4 _seconds_?

Florian Dold

2017-10-18 15:40

manager   ~0012496

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.

Christian Grothoff

2017-10-20 22:58

manager   ~0012499

Could we simply be missing an index for the DB?

Christian Grothoff

2017-11-04 18:20

manager   ~0012555

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.

Christian Grothoff

2017-11-04 18:20

manager   ~0012556

(if the performance issue is fixed, pagination can be deferred, as far as I care past 1.0).

Marcello Stanisci

2017-12-01 18:56

viewer   ~0012621

Last edited: 2017-12-01 18:57

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.

Christian Grothoff

2017-12-01 19:02

manager   ~0012622

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.

Marcello Stanisci

2018-01-16 13:39

viewer   ~0012792

Pagination added at commit c794683. There isn't any "make N transfers"-command which could be useful to test this new pagination feature, though.

Issue History

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)