Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Under load, we've noticed response times from Apache vary greatly for the same 7k image. It can range anywhere from .01 seconds to 25 seconds or greater. Unfortunately, due to corporate policy constraints we are pretty much stuck on Apache 2.0.52. I'm at best an Apache novice so I'm in over my head with this problem.

My focus recently has turned to our choice of MPM modules. We use the worker model on a dual core hyper threaded blade. It doesn't appear that swapping is an issue, and I don't see any signs of a hardware problem. I've read that worker is optimal on hardware with many CPU's where prefork it more suitable for our specific hardware profile. I can see conceptually how choosing the wrong MPM could result in this erratic behavior, but I'm not confident that it's the root cause here.

Has anyone else seen this type of range in your response times for simple static content? What else should I be looking into here?

share|improve this question

You may be hitting the client limit of Apache forcing any new clients to wait until a slot is open. See this link for more info and related Apache directives:

share|improve this answer
That is possible, our maxclients is set up to 4096, I'm not sure what I'm looking for in the logs to indicate we're hitting that wall. – user59113 Nov 4 '10 at 16:01
I don't think so with logs. The only way I've troubleshooted such an issue is with mod_status. That'll show you every request that's executing and if you have available workers. Only problem is you have to check it when you're actually seeing the issue or setup a service to monitor the machine-readable status output. – Rob Olmos Nov 4 '10 at 19:32
@Kevin Were you able to find any further insight? Was mod_status of assistance? – Rob Olmos Nov 9 '10 at 17:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.