Right panel perf#604
Conversation
will-moore
force-pushed
the
right_panel_perf
branch
from
09bfd08 to
d8e92c1
Compare
for more information, see https://pre-commit.ci
|
Just tested this on the TiM server with about 200 users in the main workshop group. Unfortunately, @Tom-TBT and I are still seeing a number of calls (projections, findAllByQueries, etc.) taking on the order of 300ms to a postgresql on the same host when loading the right-hand panel: web perf4j logLoading the same projects, datasets and images details only take sub-20ms (though mostly sub-10ms): insight perf4j logThe result of the difference is that we're seeing right-hand panel loading times of upwards of 4 seconds. |
|
@joshmoore. Do you know if this PR caused any improvement in the right panel loading times? |
|
The numbers with and without the PR were similar, with the 10ish calls of 300ms or so. |
|
By the way, the workaround we finally settled on was to move all pre-created conference users into a different, backup LDAP group and then on login have them moved back to the main conference group automatically. cc: @pwalczysko |
|
@pwalczysko "this is still a problem" - Need to find a server like learning where we can test this.. |
|
The testing setup: Connect an OMERO.web running on testing VM (...train3...) to learning server. With this PR, Images RHP values [ms]: 2687, 2836, 2736, 2752, 2675, dataset: 1008 This, as per calculation, is an improvement of 12%. |
Yes, this is an approach which we are also adopting, thanks for explaining @joshmoore - we have adapted a script which is "cleaning up" the users. But this script has to be run once-a-year manually. On another server (SLS ns), such approach is not an option even (the default group "My Data" is getting quite full). |
|
Sorry to bring up another topic (but quite important imho in this context): The biggest problem performance-wise in the "many users in the group" setup is actually less the RHP (although it would help to improve this dramatically). The main problem on the user-experience front is rather the slowness of opening images in full viewer (iviewer in our case). |
Perhaps but let me be a bit more clear. We de-LDAP'd everyone to speed things up, in that sense it's similar. But we relied on the fact that with |
Thanks for clarification. |
|
@will-moore @joshmoore I have just ran the script mentioned in #604 (comment). This removed (out of some 600 users inside the original group which needed to be speeded up) some 530 users. The effect of this removal: The waiting time of RHP is now after the click on a thumb down to 827 ms, 951 ms etc. (just giving two numbers for 2 clicks on thumbs) This means, compared with the times mentioned in #604 (comment) (around 3000 ms, improved by this PR to around 2700 ms, i.e. some 12%) we have an improvement of 66% (from 3 sec to 1 sec). |
pwalczysko
left a comment
pwalczysko
left a comment
There was a problem hiding this comment.
Sorry, was too fast with the approval. Lets wait till the GHA finishes before merging.
| {% if manager.share.isExpired %} | ||
| This {{ manager.share.getShareType|lower }} has expired and you no longer can make any comments. | ||
| {% else %} | ||
| <form id="add_share_comment_form" action="{% url 'annotate_comment' %}" method="post">{% csrf_token %} |
There was a problem hiding this comment.
What is the relationship between these changes and the proposed performance improvements?
There was a problem hiding this comment.
There was a lot of code for loading the objects for form_comment = CommentAnnotationForm(initial=initial) when that add_share_comment_form is not supported any more.
4 participants
Improves performance of loading right panel for single Objects (Project, Dataset, Image, Screen, Plate, Well, PlateAcquisition)
I looked into the timing for
getObject()withgroup: -1and found that is slower when the user is logged-in to a large group (even if that group is private).E.g. about
1 secondin the code below.It's actually faster to:
queryService.get()to get the object, get it's group ID...getObject()0.02 secondsin the code below.prints: