Evergreen DokuWiki

Use the space below to identify areas in Evergreen that would benefit from a performance analysis along with any questions that you would like a performance analysis to answer.

• Acquisitions - There are a lot of slow areas in the acquisitions. The following are some specifics I can identify at the moment
  • Going to general search takes approximately 4 seconds on our production system to display the form (C/W MARS)
  • Copies under line items take approximately 21 seconds to fully display with fund drop down in production (C/W MARS)
• Cataloging - Clicking Add Volumes or Edit Items/Volume per Bib screen is slow loading (approximate 16 seconds on our production system at C/W MARS)
• Checkout/Checkin – Slow enough times to cause workflow issues. Generally, in production it takes 1-2 seconds for this process but if the copy record has an alert message it slows to 4-6 seconds in production. On busy circ desks, things don't get checked in or checked out properly unless staff are paying close attention due to this lag time. This is happening on C/W MARS production system.
  • The alert message angle is probably coming from the "fancy prompt" being served by remote XUL and not being cached. Does a subsequent checkin of the same item result in the same delay? – phasefx
  • phasefx – There is not an issue with an alert message on checkin but if there is a holds slip or paging slip ("turtle screen") it behaves very slowly on checkin.
• Memory leaks - is there an inherent problem with the technology used in the staff client (xulrunner, Dojo) that is the source of the memory leak problem and other performance problems?
  • Testing and development shows that Dojo is not the source of memory leaks. The cause of many seems to be event handlers pinning memory at page unload time, not allowing the GC to free all memory for many interfaces. See: https://bugs.launchpad.net/evergreen/+bug/1086458 for some initial work, and there is more coming.
• Slow retrieval of patron records
  • This looks to be caused by a combination of redundant XHR requests and the use of many XHR requests in general. This theory is corroborated by the speed improvement displayed by an experimental server-side (html) version of the patron sidebar. Details to follow.
• Editing and saving patron records is slow.
• Recurring issue of a blank screen appearing on the reporter on the first attempt to load the interface. You don't see "Loading …' at all, the blank screen shows up immediately. It does usually work on the 2nd attempt, but should work the first time. – SITKA
• Recurring issue in numerous look-up areas including, but not limited to: Items out, Items Status, CheckIn, etc. "Retrieving …" shows up on screen, but the data is actually never retrieved. Usually by calling the same function again in the same or a different tab the record can be displayed properly. – SITKA
• Staff client batch operations (e.g. updates/deletes from copy buckets)
  • Can we get more specifics on this?
    • Sure, here's one example: https://bugs.launchpad.net/evergreen/+bug/921812
    • Hmm, I don't see this ^- as a general problem with Messaging. This is a specific problem with an API call and/or how the client is using it.
    • We get so many "Network Failures" with real world data that I think we have many more of these "specific problems" with how the client handles many such API calls. Deleting from buckets is just one example.

• Displaying records with many items that have monographic parts.
  • Sample record showing slow retrieval on record with 1229 copies and 1229 parts - http://egtraining.noblenet.org/eg/opac/record/3189583
  • Sample record showing faster retrieval for the same title as above, but with 1236 copies, not parts - http://egtraining.noblenet.org/eg/opac/record/972760
• Downloading CSV of large checkout history, possibly due to a timeout - https://bugs.launchpad.net/evergreen/+bug/1208875

• how does OpenSRF compare in performance (and features) to other modern messaging frameworks?
  • Perhaps an alternate question is: how does XMPP compare in performance to other messaging frameworks? Since nearly every line of code in Evergreen depends on the transparency provided by OpenSRF, replacing that layer would mean a rewrite. I don't have timing for other messaging frameworks, but OpenSRF adds between 0.5ms and 10ms per inter-application API request, and no measurable time to intra-application API requests.

• Catalog search - is there a way to optimize searching in the catalog so that users get faster results and are able to start re-implementing things like search.relevance_adjustment to provide boosts to relevance ranking? Any improvement would be useful even without the use of search.relevance_adjustment to minimize occurrences of https://bugs.launchpad.net/evergreen/+bug/1103321.
• Optimizing some queries to improve performance - do we have examples of specific queries that can be optimized?
• Post-2.4 holds targeter slowness - https://bugs.launchpad.net/evergreen/+bug/1185865

• (I'll tag my name by what I post in case anything doesn't make sense)
• combining api calls (as mentioned above) – berick
  • this is huge and it's the kind of thing that can only come after a UI has settled in.
• use streaming API responses – berick
  • We traditionally rely way too much on repetitive call and response when streaming would cut out much of the network back and forth
• reduced logging on the server – berick
• ability to force db calls to master without transaction for retrieving authoritative data – berick
  • as opposed to repetitively creating, using, then rolling-back DB transactions, which adds network (and db?) overhead.
  • I've had this idea kicking around for a while … so, I've put up a blueprint on launchpad – miker
• consider more aggressive caching (w/ cache invalidation) of things like org unit settings values, etc. within api calls – berick
• kill synchronous xmlhttprequest calls with fire – berick
  • synchronous requests cause the staff client to block pending the results of potentially long-running API calls
  • minor problems include briefly unresponsive UIs
  • in severe cases, this causes "Unresponsive script" warnings and UI lock-up

Seeking further feedback on a DRAFT RFP for Software Performance Evaluation that will be sent to potential consultants.