Google's cached pages are much faster than wiki*edia's

List overview All Threads
Download

newer

older

Request for developers: the Video...

More on testing

jidanni＠jidanni.org

1 Oct 2011 1 Oct '11

12:48 a.m.

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.

Show replies by date

K. Peachey

1 Oct 1 Oct

12:55 a.m.

New subject: Google's cached pages are much faster than wiki*edia's

On Sat, Oct 1, 2011 at 8:48 AM, <jidanni(a)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.

Platonides

1:32 a.m.

New subject: Google's cached pages are much faster than wiki*edia's

jidanni(a)jidanni.org wrote:

...

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 :)

Asher Feldman

6 Oct 6 Oct

9:55 p.m.

New subject: Google's cached pages are much faster than wiki*edia's

...

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.wikipe… 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(a)jidanni.org> wrote:

...

Jay Ashworth

7 Oct 7 Oct

4:16 a.m.

New subject: Google's cached pages are much faster than wiki*edia's

----- Original Message -----

...

From: "Asher Feldman" <afeldman(a)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 -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

Ryan Lane

4:53 a.m.

New subject: Google's cached pages are much faster than wiki*edia's

...

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

Chad

6:21 a.m.

New subject: Google's cached pages are much faster than wiki*edia's

On Thu, Oct 6, 2011 at 10:53 PM, Ryan Lane <rlane32(a)gmail.com> wrote:

...

Isn't that the same thing Facebook just caught Congressional shit for?

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

IAlex

6:34 a.m.

New subject: Google's cached pages are much faster than wiki*edia's

Le 7 oct. 2011 à 06:21, Chad a écrit :

...

On Thu, Oct 6, 2011 at 10:53 PM, Ryan Lane <rlane32(a)gmail.com> wrote:

Isn't that the same thing Facebook just caught Congressional shit for?

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

Asher Feldman

8:17 p.m.

New subject: Google's cached pages are much faster than wiki*edia's

On Thursday, October 6, 2011, IAlex <ialex.wiki(a)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.

Daniel Friesen

9:35 p.m.

New subject: Google's cached pages are much faster than wiki*edia's

On 11-10-07 11:17 AM, Asher Feldman wrote:

...

On Thursday, October 6, 2011, IAlex <ialex.wiki(a)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.

- 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]

4578

days inactive

4585

days old

wikitech-l@lists.wikimedia.org

Manage subscription

9 comments

9 participants

tags (0)

participants (9)

Asher Feldman
Chad
Daniel Friesen
IAlex
Jay Ashworth
jidanni＠jidanni.org
K. Peachey
Platonides
Ryan Lane