Background: Some testing on a 70Mbit+ connection to a remote Koha install indicates that the system is a bottleneck when it comes to issuing checkouts or returning items. If a staff user scan barcodes to fast for the system to keep up then barcodes are lost and books will not have been checked out or returned. Plack for the staff interface might solve a part of this problem, but adding a queue would be great.
Suggestion: Add a queue-box with high visibility of items that are not yet processed when checking out or returning items. If a user scans items quicker than than the system can process items the box will fill up. The system should process the barcodes in the queue-box using AJAX-code so that the whole page will not have to reload for every barcode. Ending the session (by printing receipt for checkout etc.) should not be possible until the queue is empty. Messages that today appear once per page (like holds on a title for example) will have to be duplicated since a librarian could scan multiple codes until an item has been processed by the system.
Implications on existing code: I think this might require us to rewrite some of circulation.pl and returns.pl to use Ajax, insert the queue-box and to display multiple messages at once.
According to Jared, this *might* be solved by his work on Bug 10240.
Thanks for the input. I've read up on 10240 and while it is a good patch I feel that the two are a bit apart even if 10240 might be a useful start to work with the functionality described here.
I guess it would go something like this:
* circulation.pl lights up a static page.
* scan a barcode.
* barcode is lit up in the "barcode queue"-box.
These steps can take place as many times as you like at the same time as the ones below.
* the barcode that first arrived in the cache is sent to the server for processing.
* when a response arrives form the server the corresponding barcode is removed from the cache and the visible "barcode queue"-box.
* the correct response is displayed on circulation.pl. Multiple boxes requiring to be handled could be displayed.
Before going much further with this it might be a good idea to just have a go with Plack and se if it makes the system more responsive. Not least since I have a bit of a hard time convincing people on IRC that "scan as fast as you like" is a good idea :)
This bug was filed 'pre-Plack' for staff interface and before the performance improvements done since (2013). Is it still valid?
(In reply to Katrin Fischer from comment #3)
> This bug was filed 'pre-Plack' for staff interface and before the
> performance improvements done since (2013). Is it still valid?
I think it is still valid, although not as critical as before, sometimes a network lag or waiting to db lock when making backup could make circulation process a bit slower than it could be...