 OK. I've been asked to do this one a little quick, so I will skip over a few bits and pieces during this talk. So that's an interesting looking quote I came across. That's potential, about the highest potential load you're likely to see that you come out of nowhere. I've seen at least one other presentation where someone got a similar load. So I'm talking about HTP's acceleration. I'm concentrating a little bit on the varnish web accelerator. This is a more likely load. 20,000 to 30,000 hits per second over a couple of days. Probably concentrated a bit in a few at first few hours. If you've got a proper website, you can probably handle this. Your blog at home, maybe not. So here we have a classic sort of set up internet web server, application server, running or application, running PHP, Django, whatever you like and a bit of a database behind it. And you'll be getting about 5 to 10 hits per second. I'm defining a hit as a sort of a page view. So it's a medium duty sort of thing. Maybe you'll get a little bit more. So that's, in some cases, that's a good case. Where I work, at one point we were taking 30 seconds to generate our front page and tens of seconds to generate other pages. Some people have similar, they'll have really, really big sites for various reasons. Your page will take a long time to generate. So what you can do is you can put in a data cache. So memcache is the off the shelf example for this. Basically caching your database queries and storing the result for a period. And that'll get you up to maybe 100 hits per second. Next stage, page cache. Start caching pages and pagelets of data and then squashing them and then serving them to the customer. Maybe 300 hits per second is the numbers I've seen from people. This is on commodity hardware. If you want to go past that, you are paying the big bucks. You're getting load balancers, you're getting clusters, you're getting clusters of clusters. GSLB, lots of dollars, you'll scale all the way out. And that is a very simplified picture. If you've ever run anything like this, it's tons times more complicated than that. But where do we go back? If we're generating the pages and saving them and serving them to our customers, why do we have to go all the way back to the application server to do that? Not just shove a web salarator in front of our web server and do it that way. So web accelerator, off the shelf, 1 to 5k hits per second. That's going to get you through the slash dot, it's going to get you through Reddit. It might not get you through the front page of Yahoo, but it's going to get you away there. So just as a general outline of what a web accelerator is, it caches per URLs or per pages. It's optimised to grab objects from a server behind it, caches them, serve for web pages. It talks HTTP in both directions forward and backwards. 1 to 5,000 hits per second on a commodity hardware. You can get 20,000 hits per second. I've seen people doing that in real-world situations. 100,000 hits per second on ridiculous benchmark values. Here's some examples. Squidder is very popular in Australia for some obscure reason. Varnish, Lighty, Nginx. You'll see blue-coat appliance down there that was mentioned in a previous talk. We use them at the place I'm at. We're replacing with varnish, but they're quite nice as well if you've got the money. Varnish itself, that's the URL. It's a really well-documented open source. They are releasing new versions at a regular basis, which means there is a slight problem if you see a config example. Just double-check it will work with the latest version. They're doing subtle changes, and it's used by some very, very big websites. Off the shelf it has a basic configuration and extension. Here's the basic configuration. All this does is run varnish, use this config file, listen on port 80, tells the backend server, strips out cookies, or otherwise it will serve a different page to every cookie request, and case every URL for 60 seconds. If you're getting hit 100 times a second, that'll just handle that, and it means you're only regenerating your page every minute. I'll skip this. It's complicated. How cacheable is content in general is roughly what you get. There's a big problem with that. The first four are in most cases static files sitting on a file system that you can just generate in seconds, and you don't care. The bottom two are hard to cache and expensive to generate. So you've got two opposing pressures with a cache server. You've got to keep your hit rate high on the front so you don't overload your backend, but at the same time you've got to make your content nice and fresh. Now depending on your site, there's a funny balance. You don't know how it's going to go, and there's a lot of trade-offs. The basic strategies for keeping content up to date in your cache is to expire stuff at an appropriate time. You can explicitly flush your cache, flush on a pair of object bases, and you can do silly tricks like you can use JavaScript and send out the same content to everybody and then use JavaScript to actually display different content to every person. The site I'm at uses all three of these and so do other people. This is some stuff you can push to your cache. I'll cover this in a minute. This is a person's blog. This guy's really good if you want to read a blog, but I looked at this page and I sort of realised that this is a standard off-the-shelf blog and it's probably more complicated than 99.9% of all the websites on the internet about 10 years ago. It's got so many elements in it and you can make this in 10 seconds for your grandmother. So it's got the basic content of the post, which is only a couple of articles, a couple of lines. It's got some static images over here. It's got a feed from Twitter. So if you grab this on a dynamic basis, it would go out and make a query to Twitter's API, bring it back, construct it into something. That could take several seconds. If Twitter's down, it might block and the page you'll take won't render. It's got a few static columns. It's got another... I've forgotten the word. It's hashtag cloud that's generated every time a new post is made. It's got some comments on this particular post that could be updating every few seconds. And it's got a little Twitter counter here that says he's had 21 tweets that's generated by a JavaScript query off to a different API at Twitter. So you've got some of these bits. Now this one here, the top right one, that's generated by the page, whereas the tweet count, which is generated by... Sorry, sorry again. The tweet count is generated off Twitter directly, so there's no calculation involved here. So there's two main elements that have low expire times. Everything else is only updated when a new post is made. So, yeah, if you could, you'd take that out of the equation, maybe put it in JavaScript, have it as a separate something. And finally, just hitting up the corner, there's a possibility they'll send a post and type in a completely random character and be a totally uncashable result page. So here's a few things you can do on your case to tidy up things. You can strip the URLs, so if you have funny little URLs like this, you can just strip them, so you're always serving the canonical version. This is a tiny little bit of varnish conflict that does this. Another thing, you can do mobile redirects. I haven't got time to explain this fully, but it basically has a custom error message that it uses internally to forward through to another section, and then it generates a 302 and redirects you to the mobile site for your version of your site. This is an interesting trick in that when an object runs out in your case, it basically says, keep serving this expired object for 15 seconds whilst I generate a new one. Some cases, the object expires, you're getting 100 queries a second, for suddenly you get 100 queries going to your back end. This avoids it. This is some normalisation for accepted coding for GZIP and that people do. I don't know if people here use deflate, but don't ever use deflate. If you don't know why you shouldn't use deflate, basically Microsoft implements it different from everything else. If you ever send a deflate page to Microsoft, it will not work, and you don't know this because you've always sent GZIP. So just turn off deflate. You can do simple things like change the expire times for different types of objects. This is a good trick. Varnish comes with some back end health checking. It will check to see if the back end is healthy. If it's not, instead of just keeping serving expired pages for 10 or 20, 30 seconds, you can keep serving them for an hour whilst you run around and try and get everything back up. And this is a very simplified version if you have an authentication. So people are using... There's a cookie called logged in equals yes, and all this does is scan for that cookie. If that cookie does not exist, it slightly changes the URL that people are requesting. And that slightly changed URL could just say, bring up a login page and says, please log in. Obviously this isn't secure, but you can extend that and use this sort of mechanism. And I will... The other trick you can do is edge site includes. So edge site includes is... You saw those two objects. The comments area and the Twitter bit that had very low expire times compared to the rest of the page. A trick of edge site includes is you take a bit of HTML like we have here, data CGI and you can just pull that out as a separate URL to your back end. So you would basically make your page goes construct, your overall... And then in varnish, you can have your overall page with an expired time of a day and one or two tiny little objects inside it with an expired time of a minute. And that is a very aggressive way that means you can... It really helps your hit time. There is a few caveats with varnish support right now, but it's pretty good varnish support for ESI right now, but it's all pretty good. Now the other thing to remember at the end is that occasionally your nice little management will change their logo and they will say, alright three single page on the entire website to change. And so what do you do then? You have to blow it away from the cache unless you've got some amazing mechanism not to. In which case you have to make sure your provision to do this, unfortunately. So just... I've seen a few other sites say we make sure we can handle all the pages correctly and you have to... without the cache and I would very much advise making sure you can do this. You might not handle your whole load but you can just turn on... I mean we do it at work. We reset the cache at six at night. It takes an hour or two to catch up and then it's all 100%. OK, so I'm sorry but that's a little fast but I was a bit short on to that. Any questions while the next speaker sets up? There's one over there, top left. What's the method to have the apps a server tell it to clear the cache when it knows it needs to tear it up? There is a lot of examples in the varnish doc. It's basically you send a flush. It's the standard sort of way. I just didn't include it in the slides, unfortunately. Any other questions?