Effects on Performance & Server Resources when using Apache 2.0 mod_status

June 2, 2008

I find the Apache mod_status module to be very helpful in respect to Apache server performance/usage monitoring and debugging. However I have read books and posts stating a performance hit when the module is enabled particularly with “ExtendedStatus On”, so what’s the real deal? I never hear what the impact is, in a real world setting.

Let’s outline the benefits first regarding the mod_status module and what it allows you to see (Documented on Apache’s Site):

1) Number of children serving requests
2) Number of idle children
3) Status of each child, the number of requests that child has performed and the total number of bytes served by child
4) Total number of accesses and byte count served
5) Time the server was started/restarted and the time it has been running for
6) Averages giving the number of requests per second, the number of bytes served per second and the average number of bytes per request
7) Current percentage CPU used by each child and in total by Apache
8 ) Current hosts and requests being processed

*All which can be beautifully graphed using Cacti btw for historical analysis.

I find mod_status most useful for tuning settings when using a prefork configuration, balancing the server resources and application memory usage.

So the downfall of using mod_status is upon every request Apache will perform two calls to gettimeofday. These calls are done so that the status report contains timing information. The theory is that this information is taxing in retrieval and calculation.

So as a limited but real world test using a production server I administer, I discovered only a small impact with or without mod_status enabled.

The test was on a Dell 1950 Dual Core Intel Xeon 2.0 GHz 8 Gigs of RAM Linux with Apache 2.0

I considered server load decrease as the marker for success, in that I compiled Apache with and without mod_status and looked for differences in cpu usage, memory usage, and load stats. The Apache server in question received on average 18 requests per second, mostly API application calls through PHP. And the test lasted a week for each configuration.

I saw no differences even in the slightest in server memory, nor server cpu utilization. I did notice server load was on average .29 with mod_status in extended mode compiled, and average load was .20 without mod_status compiled. So a savings of .09 on average load for a server over the course of 1 week of testing with an average 18 requests per second was seen. Regarding actual http requests I saw no speed increase or decrease.

So my conclusion, is every little bit counts however if you find that you need to tune your Apache servers often given sporadic changes in usage, you may want to enable mod_status with extended status on and reap the benefits of graphing that data using a tool like Cacti for the greater good of tuning other aspects of Apache for a more significant gain.

Comments for “Effects on Performance & Server Resources when using Apache 2.0 mod_status”

  1. Owen Boyle commented on November 11, 2008

    Interesting analysis. I have also recently started using mod_status and find it makes no difference to the server load – even in extended mode. So it seems that old chestnut is a bit of a red herring…

    I came across your blog because I was trying to find out how mod_status calculates its averages – they seem to be rolling averages over a very long period (24h?) so that they change only very slowly. If I look at a chart of ReqPerSec against time, it swoops very gently up and down over the day, peaking at 50 and dipping to 20 over a period of about 12h. In contrast, a chart of BusyWorkers is much more spiky, sharply peaking at 09.00h and diving at lunch-time and generally behaving much more like I know the traffic to be.

    Do you have any insight into how the averages are worked out and – are they configurable?

    (I guess, I could go read the code… 🙂

  2. Owen Boyle commented on November 11, 2008

    Me again… I just RTFC’d and, would you believe it, the averages are calculated over the up-time! So ReqPerSec is not a rolling average at all, it’s a life-time average. So no wonder it smooths out; if the server stays up long enough, it’ll end up a flat line.

    Not really what I was looking for – maybe it’s time to Hack-TFC 🙂

  3. Yep definitely over the period of the uptime.


    “In contrast, a chart of BusyWorkers is much more spiky, sharply peaking at 09.00h and diving at lunch-time and generally behaving much more like I know the traffic to be.”

    I find that when you run KeepAlive On that will effect the spiky BusyWorkers also. Via the KeepAliveTimeout and Min / Max Servers.

  4. Oleg Vishnepolsky commented on April 14, 2009

    Is the period over each the averages for requests per second configurable ? We need to know how many requests we are getting per second closer to real time. I would assume that this is a common request.