[FOLIO-661] Column Header Sorting is Slow Created: 05/Jun/17 Updated: 12/Nov/18 Resolved: 15/Jan/18 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Umbrella | Priority: | P3 |
| Reporter: | Cate Boerema (Inactive) | Assignee: | Unassigned |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | performance | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Sprint: |
| Description |
|
Overview: Clicking to sort user list by column header is slow considering there are relatively few records loaded. Steps to Repro:
Expected: Column should sort almost immediately Actual: Sorting works, but takes a few seconds Additional Info: If you narrow down the results to a small number (like 5 records), sorting is snappy. |
| Comments |
| Comment by Mike Taylor [ 05/Jun/17 ] |
|
The description of this one does not match the title. |
| Comment by Cate Boerema (Inactive) [ 05/Jun/17 ] |
|
It does to me Overview: Clicking to sort user list by column header is slow considering there are relatively few records loaded. Steps to Repro:
Expected: Column should sort almost immediately Actual: Sorting works, but takes a second |
| Comment by Mike Taylor [ 05/Jun/17 ] |
|
You changed the description This is an interesting issue – the first one that is truly about performance. There are many ways in which the system may introduce inefficiencies, and it will be interesting (and ultimately important) to find out in detail what is going on. But that's not something we can do overnight – it's not a matter of turning off the "sort slowly" option I am going to upgrade this from a bug to an umbrella and mark it for the next sprint. We can discuss on Monday. |
| Comment by Cate Boerema (Inactive) [ 05/Jun/17 ] |
|
Oh, I know what is happening here. I have been creating these by cloning existing issues and JIRA just asks me to add a new title, it creates the new issue (and then probably emails you) and then it presents me with the cloned bug which I then edit to create the bug I intended to create. Hmmm. I can see how that would be confusing to you. |
| Comment by Mike Taylor [ 05/Jun/17 ] |
|
Bingo! OK, well next time I see issues filed by you, I will know to leave it half an hour before looking at them |
| Comment by Cate Boerema (Inactive) [ 06/Jun/17 ] |
|
I usually have the bug fixed up in 10 minutes so no need to wait a half hour. Makes sense that this is a more general type bug - I get that. If I see any other performance-related issues, I'll link them to this one just in case and tag them with "performance". |
| Comment by Mike Taylor [ 06/Jun/17 ] |
|
Thanks, Cate. I think it will be good to start gently warming up the performance side. I added Jason as a watcher, as I am sure he'll be interested in this too. |
| Comment by Jakub Skoczen [ 12/Jun/17 ] |
|
Adding Kurt Nordstrom and shale99 because it seems that the time it takes to search is proportional to the number of recrods in the result set. |
| Comment by shale99 [ 12/Jun/17 ] |
|
i need to finish some biz logic join stuff asap so cannot look at this at this moment.
debug_log_package=org.folio.rest.persist.*
be added to the command line of mod-users? - all sql queries will than be logged with the time of execution - this will verify that it is indeed a db issue. |
| Comment by Cate Boerema (Inactive) [ 15/Jan/18 ] |
|
Actually, this seems to have been resolved. Closing. |