High Traffic Transaction Support

Following up on my last entry, I did a little bit of research trying to figure out how many transactions per second a web site is likely to see in a worst case scenario. Of course, the worst case scenario I could think of would be a slashdotting. Reading through a slew of reports, I actually found that the slashdot effect creates just over 1 visitor per second, and that number can sustain itself for 24 hours. Of course, not everybody is coming in sequentially, and when a visitor hits your site for the first time the number of objects they are requesting is not helped any by any cacheing techniques you have in place.

So what kind of load should you be measuring out if you are getting one visitor per second? That depends on a few factors.

One request per second is no problem to handle if you are serving up a text file. It's a whole different story when you are serving up html, and even moreso if you are serving dynamic content.

If you are seeing an average of 1 visitor per second for 24 hours, you probably want to be prepared to see a peak request range around two orders of magnitude higher - or 100 visitors in any given instant.

You then want to multiply that number by the number of objects you are serving up on a given page. Count up images, css files, javascript files, your favicon, and any embedded objects. Let's say there are 12 of them. You want to be able to handle 1200 transactions per second as your target.

Further, you can't download everything in 1 second, which means that the requests are going to pile up and they are going to pile up quickly. The longer your page load times, the larger your request queue will end up being. If you have 12 objects, it may take up to 30 seconds for your pages to load. You probably won't be seeing 100 visitors per second for 30 seconds straight, but during the peak you won't be seeing 1 visitor per second either. Let's say during the peak you have a maximum transaction set coming through of 100, followed up by an average of 20 visitors per second for 1 minute. During that one minute, you are seeing 256 requests come in per second for your page with 11 external references.

During that 1 minute, you'll be pushing out just over 15000 files spread accross nearly 1300 requests. Assuming a page size of 100K - you'll need to sustain 25Mb of bandwidth for at least one minute - which will require a burstable connection or a 100Mbps dedicated line.

Pushing the static content delivery to lighttpd would mean that lighttpd would be handling 14,080 of the requests, while leaving apache to only deal with 1280 of them. I would think that if apache is serving up your main content at a schedule greater than 21 transactions per second, you would end up having a site that would successfully survive a slashdotting. Your lighttpd server would need to support 252 transactions per second simultaneously - which is entirely within it's capability for static content delivery.

A further concern would be database connectivity, and this is really where persistent connections have to come into play. Configured properly, your mysql database should handle roughly 400 open connections. In order to support the transactional needs of a slashdotting, persistent connections would be a must. MySQL AB supports 4000 open connections, so if you plan on getting slashdotted regularly, you probably want to look in that direction (and put it on a dedicated server).