Forum OpenACS Q&A: Response to Open ACS handling heavy traffic
The main bottleneck on my 486-100 Apache/mod_perl server (backed by a DB on a P166) was an untuned Linux 2.0 kernel. Switching to 2.2 with a bit of tuning allowed the system to cope with the load admirably (it collapsed under 2.0). After an hour or so of proving it could handle the load adequately, I pulled the web server down, since I pay per meg for traffic. Basically, unless you're doing something complex on your pages, or have made the mistake of using a high-priced application server, grunt isn't likely to be a problem.
Lesson: find out how to tune the Linux kernel - there are a number of articles on tuning the TCP/IP parameters to speed up closing sessions to avoid your system dying from over-allocating resources. The default settings for most *ix IP stacks are based on numbers that were fine for 300bps links in 1982, but aren't realistic for modern infrastructure.
Other lesson: Bandwidth costs. About $200 for that episode...
The biggest problem, though, is that a /. mention appears to attract not merely hoards of visitors, but hoards of script kiddies. Not only were there acres of DOS attacks against my server, but upstream network infrastructure and servers on related subnets all saw a huge volume of attacks.
As far as sizing for 1.5 pages per second, think of it this way:
Each page must be ready in 0.6 seconds. That means if your average page generation time is 1 second, you're in trouble. If it's 0.1 second, you're in easy street. Log some page generation times (request arriving in AOLServer, page generation finishing). That should give you an idea of whether you're on target in terms of server grunt.
Do this on your test systems. You may be surprised - unless you're doing some horribly complex (or poorly written) things, even the lowest end Intel servers money can buy today should be more than adequate for your needs.
Consider your bandwidth requirements. Multiply out your page sizes (including graphics and the like) by the number of requests, and add 20% or so for protocol overhead, and you've got an idea if your bandwidth is adequate.
Consider your audience probably have low-bandwidth modems. That means delivery can be an issue, because most testing of pages is conducted on high speed networks. Say you're delivering 100KB pages over a 100Mb link to a client on a 10Mb link; you're taking a fraction of a second to get the finished page (one thread) and graphics (a thread each) to the client.
OTOH, when delivering to a client on a 56Kb modem, that 100KB takes a couple of minutes to trickle down, tying up AOLServer threads (and associated memory, especially) for all that time.
One approach to the problem is to have a big, complex web server (AOLServer with all the addons) built for serving dynamic content, which is often the smaller part of the page size, and a stripped down http daemon (AOLServer with no add-ons, thttpd) for serving large, static files, thereby reducing the size of threads/processes which are doing nothing but trickling data to a modem (and don't need DB drivers and the like, bloating the thread/process).
