Hoping the hackathon is still running, or folks can discuss.
Secure is pretty slow lately, day and night.... Sometimes, the revised articles don't show up for the non-logged-in, but that's easy to fix with &action=purge. I just have to remember to check after sessions.
But lately, and fairly consistently, as I've checked the history to compare with Google's cache date (not logged-in), I've discovered an old history seems to be served. "&action=history&action=purge" doesn't fix it.
Yeah, I've flushed my own local browser cache. That's not it.
The only solution I've found is to log-in insecure, check the history, and then log out. Then, the history is up-to-date for non-logged-in.
Why do we cache history?
On 23/05/11 23:37, William Allen Simpson wrote:
Hoping the hackathon is still running, or folks can discuss.
Secure is pretty slow lately, day and night.... Sometimes, the revised articles don't show up for the non-logged-in, but that's easy to fix with &action=purge. I just have to remember to check after sessions.
But lately, and fairly consistently, as I've checked the history to compare with Google's cache date (not logged-in), I've discovered an old history seems to be served. "&action=history&action=purge" doesn't fix it.
Yeah, I've flushed my own local browser cache. That's not it.
The only solution I've found is to log-in insecure, check the history, and then log out. Then, the history is up-to-date for non-logged-in.
Why do we cache history?
We don't. Maybe you're seeing replication lag rather than caching. That would explain why the secure site magically fixes itself when you do an unrelated task that takes a few minutes.
-- Tim Starling
On 5/23/11 10:00 AM, Tim Starling wrote:
On 23/05/11 23:37, William Allen Simpson wrote:
The only solution I've found is to log-in insecure, check the history, and then log out. Then, the history is up-to-date for non-logged-in.
Why do we cache history?
We don't. Maybe you're seeing replication lag rather than caching. That would explain why the secure site magically fixes itself when you do an unrelated task that takes a few minutes.
Aha, replication lag would explain it! Since I'm only doing things on off hours, how long should replication lag be these days?
Aha, replication lag would explain it! Since I'm only doing things on off hours, how long should replication lag be these days?
It shouldn't normally be more than 2-3 seconds. We did have an issue with the S4 cluster (commonswiki) this weekend where the master had crashed, and replag was very long till I brought the master back up. You could have seen some issues due to that.
We are also currently having some network issues, specifically with multicast UDP, which we use for squid purging. This could also be causing the problem you are seeing. The scheduled downtime will address the multicast issues.
- Ryan
wikitech-l@lists.wikimedia.org