search

comic / grand-challenge.org

A platform for end-to-end development of machine learning solutions in biomedical imaging
https://grand-challenge.org
Apache License 2.0
176 stars 50 forks source link

Leadersboards slow on sorting columns #3023

Closed chrisvanrun closed 10 months ago

chrisvanrun commented 1 year ago

~Not sure why, but when I view several challenge leaderboards the columns are non-responsive when trying to sort the data found within. Happens on MS Edge.~

Was a bit too quick in making conclusions. Take for instance: https://pi-cai.grand-challenge.org/evaluation/open-development-phase/leaderboard/. I tried sorting 'Created'. However, after being a bit more patient it seems it does sort but has a 5~8 second round-trip time.

jmsmkn commented 1 year ago

Do you have a link? Which columns? Extra results columns are non-sortable btw.

chrisvanrun commented 1 year ago

Updated OP. I think at least a loading indication is in order.

jmsmkn commented 1 year ago

For PI-CAI I am getting response times of 500-800ms for different column sorting when using Safari (home wifi). Slow but acceptable and within specs (<1s) for an async API view.

Screenshot 2023-09-11 at 16 37 30
chrisvanrun commented 1 year ago

Originally noticed this from the RadboudUMC, but I admit from home it feels a bit quicker (also WiFi). Same PI-CAI leaderboard:

Both MS Edge and Firefox are showing similar speeds. Initial retrieval of the page is ~180ms 'Waiting', which I assume is round-trip time.

Miriam also reports 2~3 seconds.

jmsmkn commented 1 year ago

Huh, interesting, it's also 4x slower on Firefox than with Safari for me.

james-milburn-crowe commented 1 year ago

A fairly consistent 1.82s-1.87s on Chrome (tested 3x) 4.3-5.2s on firefox 1.65-1.89 on firefox in troubleshooting mode ( as per https://support.mozilla.org/en-US/kb/diagnose-firefox-issues-using-troubleshoot-mode#w_how-to-start-firefox-in-4troubleshoot-modesf5safe-modesf)

So this looks like it could be a firefox issue, to do extensions/themes or profiles - I've not pinned that down though

james-milburn-crowe commented 1 year ago

https://datatables.net/reference/option/deferRender might be the option we need - it's highly recommended by their documentation for larger datasets. I'm trying it to see if it makes any significant difference

ignore, looks like it's for clientside rendering, and we are doing serverside.

james-milburn-crowe commented 1 year ago

Looking a little more at this, we actually have well under the datatables suggested numbers for serverside processing - I've looked at the largest challenges, and we seem to have max 500 entries on the leaderboard, datatables seems to comfortably handle clientside processing up to 5000 rows.

Unless we're planning for challenges that are an order of magnitude larger than the current largest challenge, I think we might be able to switch to clientside, hammer the server less (so one request on page load, not one each time someone filters or clicks next page), and gain a bunch of performance here.

I did a quick test, and it doesn't seem to increase initial load time - is this a possible solution, or is this going in entirely the wrong direction?

jmsmkn commented 1 year ago

No, then you'd move this 4.3-5.2s on firefox to the initial page load.

james-milburn-crowe commented 1 year ago

fair - so, tried a few things to improve this - I can reproduce it by creating a load of records in the dev site.

On firefox, creating a new profile reduced the time being taken from 4-5s to 1.8-2.2s - this seems to be a known firefox issue.

Hooking up a profiler to these shows that almost the entire time is spent waiting for a server response, on both firefox and IE - there's not a longer data rendering bit.

james-milburn-crowe commented 1 year ago

I'm not sure if there's a change from my end or on the server, but after a restart and windows update, edge/firefox/chrome are all pretty much identical - can anyone else confirm if they can still see this?

Was drawing a blank, so decided to check timings again, and they all now clock in at 1.6-1.8 for me.

chrisvanrun commented 1 year ago

Wifi from the hospital, on MS Edge: image

chrisvanrun commented 1 year ago

Testing a local dev (only a single entry) returns <150 ms. Curious if this changes if there are more records. @james-milburn-crowe maybe you can see what the increase is when you ad more records locally?

chrisvanrun commented 1 year ago

Wonder if this:

Fixes the render times here.

jmsmkn commented 1 year ago

Shouldn't do, markdown not involved and it doesn't explain why there is no issue on Safari, points to being not a problem within the Django code at all.

chrisvanrun commented 1 year ago

Doing a curl GET with the URL is ~400 ms. If I selectively add the headers that MS Edge adds, the X-Requested-With: XMLHttpRequest causes a sudden increase to 7 ~ms~ seconds. Not sure if it is intentional or highlights a path.

@jmsmkn, just for sanity. I assume Safari also adds this header in the request since it's JS in origin?

jmsmkn commented 1 year ago

increase to 7ms

?

I assume Safari also adds this header in the request since it's JS in origin?

Yes, it's there: X-Requested-With: XMLHttpRequest

chrisvanrun commented 1 year ago

Ups, meant to say 7s (shorted 7000ms but forgot to remove the mili).

jmsmkn commented 10 months ago

I think that Safari was a red herring, I was signed in as a superuser and can reproduce it when signed out. So this points to the permissions lookup. Still doesn't explain the differences James Crowe measured but I think there are big savings to be had here.

The view is already using the fast version of the lookup. But I think we can make it even faster by only considering the group permissions. We would need to ensure that the user permissions are never set.