-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The home page query for new games was flagged as a slow query #1287
Comments
Somehow, this appears to have taken down the site for a few minutes today. |
Here's what I get when I
|
Well, today I learned (or… maybe I'd forgotten and relearned?) about
I whittled it down to this:
I had a very depressing conversation with ChatGPT about this. Basically, ChatGPT thinks we have to add some kind of filtering condition to force the index to cough up the seven newest games. |
So, this looks good, but I feel there must be a better way. @salty-horse @alice-blue any bright ideas?
|
I guess we could just go back to caching logged-out results… or at least caching the date of the 7th most recently created game. |
Are you concerned about logged-in queries as well as logged-out queries? Caching seems like it would work for logged-out queries. A limit on the past N days could work for both logged-out and logged-in queries (though for logged-in queries, I guess we'd want to see how the chosen number of days interacts with sandboxes and--if the filter games PR gets merged--game filters). For logged-out queries, I don't know what makes one way better than another (caching vs. limiting days). I guess for caching, we'd have to be sure to re-run the query every time a game is added, deleted, merged, etc.? I don't know what other options there might be. Or what it was that caused this query to slow down if it wasn't being flagged as slow before. |
That I can tell you: the site gets overloaded when it tries to run "too many" full-scan queries at once. Let's say the site can normally handle 10 requests per second, and each one takes 0.1s. (I'm making these numbers up.) But if we get 20 requests per second, each one starts taking 1s. This causes a cascade where the next 20 requests come in while the previous 20 requests are still running, so each query starts taking 2s, 10s, 30s. Eventually the site starts timing out. Eventually, the wave of traffic passes (perhaps because users/crawlers notice that the site is timing out), and then the "slow" queries stop being slow… until traffic rises again. Fixing full-scan queries increases the maximum traffic capacity of the site. So:
There are way more logged-out queries (partly because search-engine crawlers are always logged out), so logged-out queries are more important, but if we can help logged-in queries, too, that's good.
Game filters is the one most likely to get tripped up by this, but I think we could probably just ignore the problem for the game-filter PR. (I've been meaning to spend more time on this… work has been busy for the last few weeks.)
Yeah, I'd say caching makes things more complex. |
I think this took down the site for a few minutes again today. I'll try to take a crack at this in the next day or two. |
It occurred to me that a limit of 90 days could affect testing in the future. Because when we're testing, we're using database contents that are up to a quarter of a year old (I think?), and with a 90-day limit, there might be a few days a year when no new games would show up on the home page, or maybe a few, but not enough games to fill the slots. |
This slow query log confuses me. It claims that the engine had to examine 14,000 rows to run this query, which really doesn't seem right to me.
The text was updated successfully, but these errors were encountered: