Fellows,
This is Google's cache of http://en.wikipedia.org/wiki/Devo. It is a snapshot of the page as it appeared on 28 Sep 2011 09:22:50 GMT. The current page could have changed in the meantime. Learn more ...
Like why is it so much faster than the real thing? Even when not logged in.
Nope, you may be one of the top ranked websites, but no by speed.
So if you can't beat 'em join 'em. Somehow use Google's caches instead of your own. Something, anything, for a little more speed.
On Sat, Oct 1, 2011 at 8:48 AM, jidanni@jidanni.org wrote:
So if you can't beat 'em join 'em. Somehow use Google's caches instead of your own. Something, anything, for a little more speed.
No we won't be doing that... Ever.
It's because they are loading a pure HTML representation of the page, where as we load lots more such as JS to make the interface usable, and they also have more (and possibly faster) equipment to handle requests, And I would also be guessing here but I would assume they have better backbone connections as well.
jidanni@jidanni.org wrote:
Fellows,
This is Google's cache of http://en.wikipedia.org/wiki/Devo. It is a snapshot of the page as it appeared on 28 Sep 2011 09:22:50 GMT. The current page could have changed in the meantime. Learn more ...
Like why is it so much faster than the real thing? Even when not logged in.
Nope, you may be one of the top ranked websites, but no by speed.
So if you can't beat 'em join 'em. Somehow use Google's caches instead of your own. Something, anything, for a little more speed.
You mean, sending arbitrarily old cached versions of the page? Yeah, that would speed things up. But I don't think that's what our editors expect from us :)
From the wmf office in San Francisco,
webcache.googleusercontent.comresolves to something geographically close and network RT time is around 25ms versus 86ms for en.wikipedia.org, 61ms in googles favor.
From chrome in incognito mode to avoid sending wikipedia cookies, it takes
me 391ms to fetch just the html for http://webcache.googleusercontent.com/search?q=cache:FXQPcAQ_2WIJ:en.wikiped... vs 503ms for http://en.wikipedia.org/wiki/Devo.
That difference of 112ms is less than the latency difference from two round trips, but the request depends on more, meaning that our squids are serving the content faster than google is. Pulling http://en.wikipedia.org/wiki/Devo from a host in our tampa datacenter takes an average of 3ms. If we had a west coast caching presence, I think we'd beat google's cache from our office, but I doubt we'll ever be able to compete with google on global points of caching presence, or network connectivity.
Note that if you're using wikipedia from a browser that has been logged in within the last month, it is likely still sending cookies that bypass our squid caches even when logged out.
On Fri, Sep 30, 2011 at 3:48 PM, jidanni@jidanni.org wrote:
Fellows,
This is Google's cache of http://en.wikipedia.org/wiki/Devo. It is a snapshot of the page as it appeared on 28 Sep 2011 09:22:50 GMT. The current page could have changed in the meantime. Learn more ...
Like why is it so much faster than the real thing? Even when not logged in.
Nope, you may be one of the top ranked websites, but no by speed.
So if you can't beat 'em join 'em. Somehow use Google's caches instead of your own. Something, anything, for a little more speed.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
----- Original Message -----
From: "Asher Feldman" afeldman@wikimedia.org
Note that if you're using wikipedia from a browser that has been logged in within the last month, it is likely still sending cookies that bypass our squid caches even when logged out.
Isn't that the same thing Facebook just caught Congressional shit for?
Cheers, -- jra
Isn't that the same thing Facebook just caught Congressional shit for?
Not even close. We don't track you from site to site, you just happen to have a cookie that didn't get deleted that also happens to cause you to bypass cache. We should likely find out why these aren't getting deleted.
- Ryan
On Thu, Oct 6, 2011 at 10:53 PM, Ryan Lane rlane32@gmail.com wrote:
Isn't that the same thing Facebook just caught Congressional shit for?
Not even close. We don't track you from site to site, you just happen to have a cookie that didn't get deleted that also happens to cause you to bypass cache. We should likely find out why these aren't getting deleted.
Well we do serve the "logged out" cookie. What real purpose that serves, I don't know :)
It certainly isn't for tracking users, that's for sure.
-Chad
Le 7 oct. 2011 à 06:21, Chad a écrit :
On Thu, Oct 6, 2011 at 10:53 PM, Ryan Lane rlane32@gmail.com wrote:
Isn't that the same thing Facebook just caught Congressional shit for?
Not even close. We don't track you from site to site, you just happen to have a cookie that didn't get deleted that also happens to cause you to bypass cache. We should likely find out why these aren't getting deleted.
Well we do serve the "logged out" cookie. What real purpose that serves, I don't know :)
It's to bypass the browser cache, and to not let the user see a page with it's user name at the top when he just logged out.
Alexandre Emsenhuber
On Thursday, October 6, 2011, IAlex ialex.wiki@gmail.com wrote:
Le 7 oct. 2011 à 06:21, Chad a écrit :
Well we do serve the "logged out" cookie. What real purpose that serves, I don't know :)
It's to bypass the browser cache, and to not let the user see a page with it's user name at the top when he just logged out.
Couldn't deleting cookies have the same effect? If we do want to set or keep cookies on logout, do they need to be included in X-Vary-Options and bypass squid caching? We could also consider loading login/userbar stuff via javascript and allow logged in users to take advantage of squid caching provided care was taken for active editors.
On 11-10-07 11:17 AM, Asher Feldman wrote:
On Thursday, October 6, 2011, IAlex ialex.wiki@gmail.com wrote:
Le 7 oct. 2011 à 06:21, Chad a écrit :
Well we do serve the "logged out" cookie. What real purpose that serves, I don't know :)
It's to bypass the browser cache, and to not let the user see a page with it's user name at the top when he just logged out.
Couldn't deleting cookies have the same effect? If we do want to set or keep cookies on logout, do they need to be included in X-Vary-Options and bypass squid caching? We could also consider loading login/userbar stuff via javascript and allow logged in users to take advantage of squid caching provided care was taken for active editors.
- Logged in user visits [[Main Page]] we send them a Last-Modified header - User re-visits [[Main Page]], they send us an If-Modified-Since, and we send them back a 304 - User logs out and the cookie is set - User re-visits [[Main Page]], they send us an If-Modified-Since, because the logout cookie is set we ignore it and send back a 200 so that they don't re-use that previous cache that had their username in the header. - ...as a side effect even after their cache has been re-freshed with a proper anon view we still continue to ignore their requests for a 304.
It is needed the way we do things right now. But I do agree it's a little off. Bypassing squids for an anon doesn't really have much purpose. And rather than this cookie hack I think the proper way to deal with the browser's cache would be with a proper ETag. Instead of Last-Modified + Cookie we have an ETag set that includes the user's user id and perhaps user_touched. Then when they log out because the ETag is different their browser doesn't re-use the cache it had. We could deal with the lack of current ETag data by putting Last-Modified in the ETag with the extra pieces. The idea of user_touched was so that things like user demotion wouldn't leave delete links in their interface. Though that may be excessive. Then again using user_touched also would make sure that a newtalk message shows up so it may be proper. For the anon ETag we would probably use something like 'anon' if $wgShowIPinHeader is on and the ip address otherwise (so that a change in dynamic ip won't leave the old ip in their header).
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
wikitech-l@lists.wikimedia.org