The documentation page has historically been notoriously slow because of all the aggregate stats it computes on the fly, often taking 10-20 seconds to load (and likely affecting load times for other players on other pages). These stats are now cached so that they will be computed at most once per hour, thus greatly increasing the page's speed when the cache is hit.
announcements
Administrator |
|
<Apex>
|
Yay so now theoretically the 20 second load time will only be once per hour total. |
|
caching ftw |
|
Trio, the 20 seconds would be completely on server side. You won't even know it happens most likely. |
|
Hmmm.... so the page only loads fast if it was already cached, but if you are the first person to check the documentation page in the last hour it'll still be slow. Note: These values are cached and therefore may be out of date. [last computed 21 seconds ago, eligible for recomputation in 3,579 seconds] |
|
Yea, that's how caching generally works. If 100 people visit a page, instead of generating the same page 100 times, it's generated once for the first visitor, and stored in cache (file or memory) so it's ready to use for the 99 others. After a while, the cache is cleared, so a new one needs to be generated. Which happens at the next visit. So if the documentation section is visited only once every 1,5 hour or so, no one will ever see a cached version :) I just looked, and got a brand new version as well; |
|
good work ender although who shall be the unlucky one and have to wait that 10-20 seconds |
|
It could be a cron job. It refreshes itself every hour. |
Fishwick [131] Moderator |
"Eligible" suggests otherwise |
|
Note: These values are cached and therefore may be out of date. [last computed 0 seconds ago, eligible for recomputation in 3,600 seconds] I was the unlucky one! |
|
me too maybe a cronjob isnt a bad idea :) |
|
Doubt more than one person an hour checks it really. |
|
[last computed 0 seconds ago, eligible for recomputation in 3,600 seconds] I guess DNM is right... |
|
i support the cron job Note: These values are cached and therefore may be out of date. [last computed 0 seconds ago, eligible for recomputation in 3,600 seconds] |
<Storage>
|
Yeah, It sucks being that one guy. Note: These values are cached and therefore may be out of date. [last computed 0 seconds ago, eligible for recomputation in 3,600 seconds] |
|
Whats the average amount of visits to that page per day? it can't be that many if you guys keep having to wait so long |
Administrator |
I'll look into automatically populating the cache. |
Administrator |
There doesn't seem to be a way to do low-priority/background SELECT queries in MySQL. These queries are the source of the slowness, so the naive approach of automatically triggering it every hour would probably cause a noticeable slowdown for other requests during the refresh window (I have not actually verified this though). Automatic cache loading may still be worth investigating, but for now, I've simply bumped up the cache lifetime so that the stats are loaded at most once per day (up from once per hour). |
|
How about letting us force/ask for a refresh of them? |
|
Heck make it once a week. No-one really needs stats that hardcore do they? *hides* |
|
Liar, you like to check your spamcount after every post. |
|
Note: These values are cached and therefore may be out of date. [last computed 0 seconds ago, eligible for recomputation in 86,379 seconds] how shit does it actually feel when it happens to you :( |
|
If this makes you feel shit, don't watch the news, or go outside. |