Differences

This shows you the differences between two versions of the page.

--- dev:testing:performance_issues [2013/03/18 14:29] – klussier
+++ dev:testing:performance_issues [2022/02/10 13:34] (current) – external edit 127.0.0.1
@@ Line 10: / Line 10: @@
     * 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.
@@ Line 15: / Line 16: @@
       * 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 [[http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/alt_patron_summary|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?
@@ Line 25: / Line 28: @@
       * 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
 ====Messaging(OpenSRF)====
@@ Line 32: / Line 36: @@
     * 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
 ====Thoughts on General Improvement====