Hello,

I´ve read in some docs that enabling keepalive could optimize apache, but every time that I turn it on, my server load went high by 4x.

Is this normal?

These are my settings.

Keepalive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

Thanks in advance, Simon.

It depends on what you are doing with the server, are you doing shared hosting or something special?

Nothing special eth00. I host a site with 100K daily visits, who uses a c cgi intensively, and 2 small (2K visits) php sites. I have a bunch of free memory, but in the peak hours my load went up too high.

On CGI intensive sites, Ive had a lot of luck on turning keepalive down or off, and using a light httpd daemon to serve up images with keepalive on. On a simple page request, my benchmarks were showing the page loading and sending images in half the time it would take for having apache do everything. When I really started benchmarking intensively with concurrent requests and thousands of hits, I saw a 10 fold increase in transfer times.

What is your max clients?

In your case it might be too many concurrent connections and with keepalive holding them open you eat up memory until it starts to swap then it's downhill from there.

Depending on the amount of images you have on a page, Keepalive can be beneficial or it can hurt performance.

Consider also using Tux to serve up images, and only using apache (or something other http program) to run your cgi script.

Hi,



as has previously been guessed, you may have a memory-problem with those settings -- especially if your apache is not just apache itself but also carries, say, mod_php (or other, similarily big, modules) in every process. Keepalive itself is a good thing for performance for your visitors if you have a lot of content to load for a pageview (since then, not every request will have to initiate a new TCP connection, but rather a previously existing one can be reused. The time to open TCP connections for, say, 50 images adds up, quickly, and makes for a shoddy user-performance, subjectively).
The flipside of it is that your connections will potentially stay open a quite a bit longer than usual (5 seconds at the least), tying up that apache process. If no more requests come in on that connection, it is essentially dead and useless, but can only be reaped 5 seconds later. If many such connections pile up, you may indeed run into memory- or MaxClients-problems if your apache is big or not configured to handle that kind of load.

There are a few different ways of rectifying that and still taking advantage of KeepAlives. You could host your static content on a different HTTP daemon (tux, thttpd, or even a lightweight-apache without big modules -- maybe even a threaded apache2.2). This would require you to make changes to your webpage so as to load static content from a different URL.

You could also go for a tiered setup; Have a very lightweight apache in the front (without much of anything in the way of modules, but a generous MaxClients/ServerLimit setting and a decent-sized tcp connection proxy cache (65k-500k per connection), depending on your content. This "frontend" would handle static content and keepalives elegantly; anything dynamic that needs an apache module is forwarded by mod_proxy to a backend apache running on the same machine (with keepalive disabled, and considerably smaller MaxClients-setting); you can probably get away with running the C CGI program from the frontend though, assuming it is indeed plain CGI and not mod_fastcgi or mod_perl or such), since that will hardly eat may resources, apache-wise.
The effect you would want to achieve with this is that, while the frontend server may be busy serving hundreds of connections at the same time (many of which keepalive), it will not use much memory (since the frontend apache footprint will be small), the backend apache will only have to handle the truely dynamic pages; and due to the TCP Connection proxy caching in the frontend, the backend my calculate its page output, send it off to the frontend in a split-second, close the connection, and work on a different one -- while the frontend is still potentially delivering the previous output to a (potentially very slow) client. The backend apaches may use more memory even, since there are so few of them (so eAccelerator with generous settings, for instance, can be an option).
(I have used this setup in the past, and it scales extremely well, especially on sites making heavy use of mod_php)

If even that is not enough, you can look into a similar setup with a fully configured backend apache (just like you are running now) with disabled KeepAlive, but having Squid handle the frontend as an accelerating Web Server. Squid is extremely efficient if set up right, and can take care of your static content semi-automatically (by caching it); the backend would only be hit for dynamic pages, which receive the same benefit as when used in conjuntion with a frontend apache, that is, Keepalives and slow connections are handled by Squid, not the backend.

None of these options are implemented with a simple config file change though (and listed in ascending order of difficulty -- and reward), so if you are happy with your site's performance with disabled keepalive, by all means, go that route