Loading of Works page is painfully slow

[tfmorris]

Related to the goal of merging works & edition pages (#684), the current works page is too slow to be viable as a basis for the primary book page with page render times of over 20 seconds once a work has more than 100 editions (e.g. Plato's Phaedo)and regular timeouts for works like Plato's Republic which have a few hundred editions.

A core problem seems to be that all information for all editions is loaded up front even though the UI is paginated and the sure only sees a few editions at a time. This is a waste of time which doesn't benefit the user.

The fact that subsequent page loads aren't any faster would also indicate that caching is ineffective/broken.

[tfmorris]

Some highlights from a brief analysis of the works page for Phaedo (124 editions) which renders in about 20 seconds.

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
     103   17.549    0.170   17.549    0.170 ssl.py:254(read)
       92    0.806    0.009    0.806    0.009 ssl.py:401(do_handshake)

Basically all the time is being spent waiting for API calls, but it's impossible to tell what those calls are from this view. The high do_handshake ncalls may indicate that SSL connections aren't being reused.

models.py:609(get_sorted_editions)                  <- editions_datatable.html:1(__template__)(1)   19.847
...
client.py:756(get)                                  <- LoanStatus.html:1(__template__)(153)   19.007
                                                       edition-sort.html:1(__template__)(196)   19.612
                                                       models.py:291(get_realtime_availability)(53)   17.067

Unsurprisingly, fetching the data for each edition seems to be taking the bulk of the time, although a) 2 seconds per edition seems very high and b) there's a hint that perhaps it's entirely the fault of checking for loan status/availability.

[mekarpeles]

Here's a full trace: https://gist.github.com/mekarpeles/b7fdb608867ecc3afaa9a92db301ef57#file-works-txt-L1505

[mekarpeles]

@tfmorris reports:

Turns out that there’s a super simple fix. Remove the loan status from the works page and page render times will drop from ~30 seconds to 2-3 seconds for works which have ~75 IA editions (non-IA editions are effectively free).

[tfmorris]

Oops, this ended up as a comment on the gist instead of here:

Thanks. How many total editions was that for? There appear to have been 73 editions with IA identifiers. Of the total 27.85 seconds, getting loan availability appears to have accounted for the vast majority of the time.

models.py:291(get_realtime_availability)            <- LoanStatus.html:1(__template__)(73)   26.717
                                                       models.py:291(get_realtime_availability)(73)   24.567

Ripping that stuff out would be an immediate fix for the performance issue. What user cares about the availability of more than the edition that they think they want to borrow? They certainly don't care about the availability of 63 editions which aren't visible on the page.

[LeadSongDog]

Just spitballing: if the availability is removed from the works page, might there be a way to prefetch it, so that when the user hovers on a "borrow" the status can be shown promptly?

[seabelis]

Can the edition list be changed to a pager? Not only are works pages slow to load, they are also slow to navigate; if you want to go to the last page of a long list you could end up scrolling through hundreds of editions.

[mekarpeles]

We'll still have availability... it will just be fetched in 1 go (as a batch), rather than checking availability for many books individually.

There are additional optimizations we can add to improve navigation (cc: @seabelis); I prefer if we address this as / create an independent issue :)