http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15147 --- Comment #2 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.