Bug 15147 - Blocking Calls in Patron Search
Summary: Blocking Calls in Patron Search
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-06 10:17 UTC by Martin Renvoize
Modified: 2023-08-27 14:32 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Renvoize 2015-11-06 10:17:39 UTC
Patron search is just plain slow since the whole converting datatables to ajax.

This is because the main route into searching for patrons is the top search box, and that search in fact fires a series of blocking requests instead of asynchronous ones.

This can be seen clearly from the chrome dev tools networks tab.  One long running request to members.pl followed by a non-trivial call to svc/search.

This is fine once, but if you then change the search term inside that top box, the whole procedure is fired again.

We were better off before the Async work as the search was done as part of the initial members.pl piece. The page was slow to load, but at least it yielded results straight away rather than having to fire a second request only after the page had loaded.

The best solution would be to do it properly asynchronously. Load member.pl only once in the lifetime of a session perhaps and utilise caches to keep it clientside.. then a search would always just fire the svc call and thus yield a much faster search experience.

There are a bunch of places were doing async totally wrong, but this to me is the most obvious and the one that's hurting our customers the most.
Comment 1 Jonathan Druart 2015-11-06 15:56:43 UTC
(In reply to Martin Renvoize from comment #0)
> Patron search is just plain slow since the whole converting datatables to
> ajax.
> 
> This is because the main route into searching for patrons is the top search
> box, and that search in fact fires a series of blocking requests instead of
> asynchronous ones.

I see only 1 request to svc/search, what are the others?

> This can be seen clearly from the chrome dev tools networks tab.  One long
> running request to members.pl followed by a non-trivial call to svc/search.
> 
> This is fine once, but if you then change the search term inside that top
> box, the whole procedure is fired again.
> 
> We were better off before the Async work as the search was done as part of
> the initial members.pl piece. The page was slow to load, but at least it
> yielded results straight away rather than having to fire a second request
> only after the page had loaded.

The idea was to use the top box to launch the first search, then use the filters on the left when you are on the result page to refine the search.

> The best solution would be to do it properly asynchronously. Load member.pl
> only once in the lifetime of a session perhaps and utilise caches to keep it
> clientside.. then a search would always just fire the svc call and thus
> yield a much faster search experience.

What do you want to cache here? There is no need to cache.
What I understand from your need is to make the box on top behaves the same as the filters.

> There are a bunch of places were doing async totally wrong, but this to me
> is the most obvious and the one that's hurting our customers the most.

I don't see any other.
We only have the lists and the checkouts using DT + Ajax
Comment 2 Martin Renvoize 2015-11-10 09:47:36 UTC
We're doing some further investigation here at PTFS Europe.

We've found that none of our customers do a search and then alter the search with the filters on the left.. they usually use the top box again.. "It's up front and centre". I'd put money on most libraries doing the same ;)

It's the call to members.pl followed by svc/search I was not happy about. That's the blocking sequence, there are no further calls to /search.. but any secondary search (executed from the top bar as is nearly always the case) results in that same blocking sequence. (Meaning you have the startup cost of cgi twice, the startup cost of DBIx::Class twice).

Regarding caching, the Patron Search Results page is pretty much static.  Thus the response from members.pl should be eminently cachable in my mind.  This certainly needs investigation though as I'm not sure without digging what else that call does.. but basically I feel that page should pretty much be in memory so any subsequent calls to member.pl use the local copy (i.e are instant) and then only the /svc/search call is fired from the ajax request and datatables.
Comment 3 Petter Goksøyr Åsen 2016-10-13 08:48:23 UTC
If anyone is working on this, see my comment on bug #1707
Comment 4 Katrin Fischer 2023-08-27 14:32:29 UTC
I believe this to be no longer valid with the move to API driven patron search. Please reopen if I am mistaken!