You are reading a single comment by @fizzy.bleach and its replies.
Click here to read the full conversation.
-
Would that mean that while a user is reading page 1, the subsequent pages would be being fetched and...cached for loading?...
Sorry I'm not massively familiar with this level of coding.
fizzy.bleach-
Ooh, that's a good idea.
It didn't mean that.
It meant that "page 1 is fast", "pages 2 and onwards are a little slower".
But... hey, I could prefetch the next search page and then when you click the link the browser either has it, or the server has already cached the query... either way that would be fast.
Cool.
So my changes this evening (when I get home) will be:
- Split the search query into 2 queries, one that does the search and one that counts the results.
- Add a prefetch meta header to the search results page.
- Entirely unrelated, add a meta header to prevent sending referrer headers off-site, which improves privacy.
- Split the search query into 2 queries, one that does the search and one that counts the results.
Velocio
I've just confirmed that running it as one query (do the search and figure out how many results there are whilst only returning the first 25) takes 1 minute and 38 seconds.
Running it as two queries (do the search, return 25 rows and then figure out how many results there are) takes 2.5 seconds in total.
Definitely will change this.
Though... there is a risk that the search will be slower on subsequent pages. i.e. it may take towards 15-20 seconds (and risk timing out on some queries that return very large result sets) to fetch page 2 or more.
In essence I had chosen to implement a way of searching in which the cost for all pages was equal, but it's probably best to tune for making page 1 very cheap, and subsequent pages expensive.