search

PRIDE-Archive / xi-mzidentml-converter

Apache License 2.0
0 stars 0 forks source link

Check Loading time #45

Closed sureshhewabi closed 5 months ago

sureshhewabi commented 6 months ago

Check loading time specially when it load first time. Investigate if any caching is required

colin-combe commented 5 months ago

Django and FastAPI respond slower than usual in their first API call. Flask always stays consistent but is much slower than the other two during all API calls. (https://dev.to/fuadrafid/fastapi-the-good-the-bad-and-the-ugly-20ob)

I think the FastAPI first response is so slow that it's a problem.

There is test code here - https://github.com/colin-combe/api-speed-test. It executes the same SQL as the endpoint /pride/ws/archive/crosslinking/pdbdev/projects/PXD019437/residue-pairs/based-on-reported-psm-level/all would. (It uses the same upload ids as you have in your production database.) Its a flask app kept as simple as possible, but afaik its a fair comparison.

The flask test app does indeed stay consistent in its performance. For me it takes about 20 secs to load response in browser, running the falsk app locally.

The FastAPI endpoint /pride/ws/archive/crosslinking/pdbdev/projects/PXD019437/residue-pairs/based-on-reported-psm-level/all) is, i think, always very slow for the first query. For me more than 3 minutes to load response in browser, running the api locally. Subsequent loads may speed up (for me, to about 15secs).

Maybe disabling caching in FastAPI would help, but this doesn't seem easy https://github.com/long2ice/fastapi-cache/issues/37

@sureshhewabi - you may want to do this test yourself and see if you get the same results.

The short consistent time is what we want, though i'm not saying we should necessarily use flask. The very long delay on first load is a problem, reopening...

colin-combe commented 5 months ago

ok... i can't reopen. But it should be reopened.

colin-combe commented 5 months ago

The FastAPI endpoint /pride/ws/archive/crosslinking/pdbdev/projects/PXD019437/residue-pairs/based-on-reported-psm-level/all) is, i think, always very slow for the first query.

So, I was wrong about that.

Suresh made an equivalently simple FastAPI test and it performed faster than Flask on first response. I checked and got same result. I should have done that other test tbh.

Then I checked xiview-api and it was fast, including first time. Different behaviour from that i saw yesterday.

Then it started happening again. I've been looking at time to load in browser when i make these claims, which is probably a mistake coz browser could do funny stuff. But weirdly, when it's happening it will happen even if browser and server are restarted, when running server from command line so no funny stuff from IDE, and I'm keeping an eye on system monitor to see that nothing's holding onto resources.

I think it's probably browser weirdness.

@sureshhewabi - could you try the following just to check for weirdness on server side?