[OPEN-ILS-GENERAL] ***SPAM*** Re: Acquisitions issues

[Jonathan Field]

We've also had reports of very slow loading purchase orders where there 
are a number of items in the list and it is causing real problems for 
the libraries involved. It should be said that 50+ lines on a PO at this 
library is the norm and most go into 100s of lines!

We've checked through the code to try and work out what is causing the 
slowness, our original thought being that it must be something to do 
with network requests or database performance. Having found the calls to 
the database we can run the same calls in the opensrf shell and get a 
full response in 7 seconds for a purchase order that takes over four 
minutes to load in the client (approx. 300 order lines):

request open-ils.acq open-ils.acq.lineitem.search 
"<auth_token>",[{"purchase_order":<po_id>}]

Digging a little further, it seems that CPU usage immediately jumps to 
100% when loading an order. Using a PC with four processors and 8GB RAM 
does speed up the process by about 50% but this isn't a spec we would 
expect to see in a branch library! It also gives an indication that it 
is the client performance rather than network or database requests that 
are causing the slowness.

This seems to be confirmed by comparing the same transaction through a 
web browser rather than the staff client. Google Chrome seems to perform 
best. A 300 line order which was loading in the staff client in 4 
minutes is loading through Chrome in about 12 seconds. The performance 
in FireFox is not quite as good but is considerably better than the 4 
minutes.

In the staff client, the scrollbar at the side of the screen gets 
smaller quite quickly as the order lines are loaded but then the client 
becomes unresponsive leading us to guess that the problem is with the 
javascript routines that sort/extract the information and renders it to 
the screen. Looking at the amount of code behind the discovery, 
rendering, and processing of the purchase order display we'd guess it 
would be a considerable undertaking to address the issue?

However, we're continuing to look at this (whilst the library 
acquisitions staff uses Chrome as a workaround). We've tried disabling 
the book jackets on the PO for example which has made a small 
improvement. If anyone has any suggestions as to anything that could 
potentially be disabled to speed up the rendering process we'd be really 
grateful. However, in the meantime, we continue to investigate and will 
endeavour to feedback anything we find.

Thanks
Jonathan



On 30/04/2012 23:10, Tara Robertson wrote:
> We are part of the second slightly larger group of ACQ pilot libraries
> in Sitka. I'll leave it to the Sitka Project Manager and Acquisitions
> Support Specialist to speak to the wider consortial issues with ACQ.
> However the biggest issue for us is the performance--it's very, very slow.
>
> For example, it took about 4 minutes to load a selection list with 120
> titles on it. It took slightly less time (but still unacceptable for
> staff) to load a list with 80 titles on it, a list with 50 titles takes
> about 15-20 seconds. Many screens take a long time to load. We are on
> excellent broadband in an urban area, very close to the data centre, so
> I don't think the network is the issue. This is the main frustration for
> staff. There are many other medium and small frustrations. We are a one
> branch library with one fund, so we are the most simple configuration
> that can likely exist.
>
> I look forward to hearing other people's experiences with Acq and look
> forward to how this module will develop. I realize that the development
> roadmap is very high level, but I don't see anything related to Acq
> listed in future releases. (BTW--thanks to whoever updated the roapmap!)
>
> I wouldn't say that Acq doesn't work, but currently we are finding it
> very cumbersome and staff are nearing the end of their rope.
>
> Cheers,
> Tara

-- 

Jonathan Field
Technical Director, PTFS Europe Limited
http://www.ptfs-europe.com