| Issue Number | 4377 |
|---|---|
| Summary | [Summaries] Changes to Summaries Report very slow on QA |
| Created | 2018-01-08 21:32:13 |
| Issue Type | Inquiry |
| Submitted By | Osei-Poku, William (NIH/NCI) [C] |
| Assigned To | Kline, Bob (NIH/NCI) [C] |
| Status | Closed |
| Resolved | 2018-03-07 14:22:57 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/ocecdr/issue.219472 |
The Changes to Summaries report is very slow even in cases where it doesn't retrieve any documents. I am not sure if this is related to the current changes but compared to the PROD, it is several times slower.
Given what the report is being asked to do, it's astounding that it
finishes at all on the lower tiers. In the worst case, it has to
retrieve almost 20,000 XML documents (19,329 publishable versions for
the 633 summaries), some of them fairly large, and examine each one. The
fact that it does this more slowly on a non-production tier is not that
surprising, and the fact that it takes longer (much
longer, usually) when there is nothing to report is expected. Think
about what it has to do. When a summary has recent changes, and you give
the report a recent date range, the software only has to look at only a
few publishable versions (often only one) in order to find the most
recent one which has a DateLastModified element with a
value which falls in that range. Now picture what happens on a lower
tier, which isn't getting all of the activity for Summary maintenance
which happens constantly on the production tier. For each summary, it
has to keep walking backwards until it runs out of publishable versions
to look at. We can talk about revisiting the logic (for example, assume
no one will ever save a version which predictively gives a
DateLastModified in the future, and maybe even assume that
no one will ever save a version with a DateLastModified
date which is further in the past than some length of time), but I'm
going to ask that we focus on bugs introduced by the Gauss changes, and
leave optimizations of the already existing logic for Hawking.
I have modified the title and It's now in Hawking for consideration.
I've gotten it down to about a minute on QA by cutting some corners, eliminating support for unlikely edge cases.
It appears to be significantly faster now. Thanks!
Verified on QA.
Verified on PROD. Thanks!
Elapsed: 0:00:00.001420