How many Hits can I handle?

mpm_prefork

[fruitwerks]

I have not been able to get a square answer on this one. I want to know what kind of load I can handle. I was told to find my RSS for apache (32mb) and work that into how much ram I can give it (~3gb). Knowing this I calculated that I can have the following config and be relatively safe;

<IfModule mpm_prefork_module>
StartServers  12
MinSpareServers 8
MaxSpareServers 90
MaxRequestsPerChild 0
</IfModule>

Now My real question is, how many hits can I serve up at once assuming no bandwidth restrictions? This topic appears to be one of the 'secrets' of apache admin. Any help, answer, corrections, or whatever is appreciated.

Thanks!

[jdMorgan]

It's not that it's some 'secret.' It's just that predicting how many requests a server will be able to handle involves so many variables that it's a near-impossible job.

Frankly, I suspect that admins who do not have access to a test set-up including a test-traffic-generator machine probably take the time-honored approach of "Throw it on-line and see if it crashes under the load." :)

For an example of the difficulties involved, there's the first issue: How do you define a "hit" in your question above? I mean, what is *your* meaning?

Is that a fetch for a sinlge file of fixed size, as cited, or does it include other object fetches, like HTML pages, plus each of the included objects on those pages. It's all very detailed, and makes my brain hurt. :)

Then of course there's the issue of server hardware performance -- How good is that server, really? What about the disk subsystem? -- Thousands of variables to consider.

Oh well, don't feel bad: Newton's equations for mutual gravitation can only be solved precisely for two-body (two-variable) systems. The computations to solve precisely for more than two bodies would take longer than the current age of the universe to complete...

Jim

[lammert]

The mpm_prefork settings just configure the maximum number of Apache instances, not how efficient these instances are used.

The number of hits which can be processed at any moment is dependent on the number of free Apache instances. Free doesn't necessary say they are working. With KeepAlive turned on, many Apache instances will be waiting for closing the connection and only few will be responding to an actual request. With KeepAlive turned off many Apaches will be serving individual requests, but few will be waiting for the connection to close.

The optimal setting of KeepAlive of your server will highly influence the concurrent number of hits it can take. The optimal setting depends on your site architecture and audience. Sites with very few images, CSS and JS files per page in general benefit of not using KeepAlive times. Fast sites with mainly broadband visitors may perform better with a short KeepAlive time while slow sites serving people on slow connections may need a long time. Only thorough testing will give you the optimal settings for your site.

Looking at your situation, 90 instances of 32MB may well use more than the available 3GB. You need to keep some spare room for the operating system, caching and other running processes to prevent significant swapping to occur.

Setting MaxRequestsPerChild to a non-zero value may also benefit memory usage because this causes fat apache instances to be replaced eventually by new small ones.

[fruitwerks]

Thanks for the info! Yeah this is really a hard subject to deal with - I see why there is a lack of 'love'. Since I have applied the above settings, we have not had any downtime issues. I have never had to modify such settings before. I have done a few big jobs, but never hit this issue. Most of the sites hosted are 'average' but we do have a lot of cgi requests. Might the issue be related to CGI and not apache availability?

Like I said, it is working - so far, but with all the large CGI requests I might be facing a totally different issue?

[lammert]

The only way to really know where your problem is, is testing and monitoring. It is difficult for us on a forum to know what causes the server downtime. You might consider installing a monitor package. A good monitor package records use of resources every few minutes which gives you an idea of the origin of the downtimes. A free monitor package is Munin, which records the state of the most important server stats every five minutes and generates graphs of it. But there certainly are other solutions which can give you insight in system bottlenecks.