@grace I think some care needs to be taken with how we’re benchmarking things here. For example, in the first screenshot, the request for the login locations indeed takes over 500ms. However, if I run the same request on my local, it takes about 200ms and if I run it directly on the same server, about 170ms. If you look at the same screenshot, the response for the request to get the list of installed modules takes 334ms, but locally for me, around 34ms (I didn’t measure this on the server). This means that the bulk of the slowness in the test here is due to network latency (apparently on the order of 300ms).
Now, even 170ms is probably a bit slower than we want, and there’s probably a low-effort way to speed that up further, by actually adding an index on the location_tag.name column, which we need to search to filter the logout locations.
I sort of suspect (but can’t tell because no timing data is in the screenshot) that something similar is going on with the 3 second thing. In any case, dev3 should not be used for performance sampling, because it redeploys relatively frequently and makes some dev-specific assumptions and when we do, we need to have a decent measure of network latency. The browser dev tools detailed timings can give a very useful breakdown. For example, here are the timings for my browser from the request for locations and the request for modules:
In the first screenshot, we see some additional latency (~64ms) due to the TCP handshake and TLS startup. This can help us factor out some of these issues.