Every now and then a bunch of really slow HTTP clients decide to suck down pages off my web site. This is bad because when enough of them do this, it dramatically lowers the number of free Apache processes available to handle requests from the rest of the world. I don't know if it's some lame DDoS attack or just really slow clients.

In years gone by, I know that lingerd was a solution to this problem. But there doesn�t appear to be much activity around it these days. In fact, the lack of a lingerd package in Debian (there is an old unofficial packagae) suggests that there are better methods.

I've been using mod_limitipconn to partly deal with the problem, but I need to keep that number high enough that it doesn't penalize normal browsers. That makes it a sort of half-assed solution. It occurs to me that I could put Squid in front of Apache, but that seems a little heavyweight. Or maybe my impressions of Squid are skewed.

Anyway, I'm looking for ideas or pointers to the obvious thing I've missed.



If it was a DDoS attack you would seem many such connections from multiple locations. You don't give any stats in your question so we can not really judge.

If many of the slow requests are coming from the same location, especially if they are for a large object, it could be that you have people opening many many connections using a download manager.

If you are not locked into Apache for specific reasons you could consider a move to a server that is based on an event driven architecture rather than a threat/process based one, such as nginx. These allow the number of concurrent connections to scale much more efficiently as each basic request requires very little by way of extra resource (particularly RAM) - though the scalability on requests for scripted resources can vary a lot depending on your setup, getting the efficiency of modPHP (unless you already run it in (faast)CGI mode) can be more work to setup for instance, and of course you might be using other modules/features not well supported away from Apache.

You could also just allocate more RAM and increase the maximum number of Apache processes/threads.

A mid-way between those two solutions is that if the slow requests are for static resources you could use light-weight web server to serve the static content (in much less RAM than Apache would) and proxy the scripted requests (and other the require the extra features other than just serving a file) to Apache's setup. Many large heavily loaded sites operate in a similar manner to this.

Off the top of my head I do not know of a method that limits the amount of time a single request can take - this would probably not solve your problem anyway because in both a DoS situation or in the case of download managers a new connection will immediately be attempted.

  • So, david you mean to say i should use NGINX in front of appache to sort out this problem. – Zahir Jul 16 '10 at 10:51
  • Possibly, but it depends on details you should add to your question: what are the long running/slow requests actually requesting? Scripted responses, static files or a mix (if so what sort of mix)? Where are they coming from? The same location, different locations but several from each, or apparently randomly distributed? – David Spillett Jul 16 '10 at 11:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.