[23:13]<Dantman> @_@ 1GB bandwidth on that server already [23:24]<dmachi> Dantman: you can probably reduce that (and make the site faster) by placing the static resources in a versioned directory and then use far future cache headers. [23:25]<Dantman> Hmmm... MediaWiki IS supposed to update a variable when static stuff changes [23:26]<dmachi> actually it looks like the images might be versioned by the directory being requested, but not the css. But what i mean is that with the current caching approach there is still a round trip to the server [23:27]<Dantman> No, images aren't versioned [23:27]<dmachi> (I can't say whether that is easy to do with mediawiki, was just looking at the requests) [23:28]<dmachi> hmm, ok [23:28]<Dantman> That's the hashdirs which are to get arround slowdowns when you have a lot of files (so they're not in the same dir) [23:28]<dmachi> what is teh /a/a4 stuff [23:28]<dmachi> oh [23:30]<dmachi> well if you can make it so the url contains the version (so links can be changed easily), then you can set far future headers for cache rather than using e-tags. Since I imagine a lot of viewers are repeats and developers, its likely to have pretty good browser cache hit [23:30]<dmachi> s [23:30]<dmachi> Dantman: anyway, not saying its critical either, was just making an observation based on your comment :) [23:31]* Dantman doesn't think that can be done [23:31]<dmachi> with mediawiki you mean? [23:32]<Dantman> mhmm [23:32]<dmachi> k [23:34]<dmachi> Dantman: hmm, there is at least a patch here (didn't read the whole thread though), http://www.mail-archive.com/wikibugs-l@lists.wikimedia.org/msg07296.html, though its a year and a half old so i'd guess there is something their current version by now? [23:37]<Dantman> Nope [23:37]<dmachi> oh well [23:37]<dmachi> anyway, good luck. Looking good so far regardless. [23:38]<dmachi> gotta run for now, ttyl