httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [users@httpd] Re: Throttling in apache
Date Sat, 20 Jun 2009 11:38:41 GMT
Mohit Anchlia wrote:
> Could someone please give some suggestions?

1) In the general sense, what you want to do amounts to "rate limiting". 
I'd suggest you Google for these words.
2) considering the very specific nature of what you want to do below 
however, I doubt that you'll find a ready-made tool to do it.
Sometime unfortunately one has to do things oneself.
3) the very nature of HTTP is request-oriented.  Which means basically 
that each request/response is handled separately, and HTTP itself has no 
"memory" spanning several requests.
But what seem to want to below would require just that : something that 
"remembers" how often a specific client (or application, or both; that's 
not very clear) has sent requests to the server within a given past 
period of time.  Basically thus, what you want to do is not at the HTTP 
level, but at the application level. So you are unlikely to find it 
ready-made here (meaning on the Apache site).
4) The way you describe the logic below, it looks as if whatever 
mechanism would achieve it, would need first to parse the XML body of 
the request, in order to find that "application-id" in it.  I would say 
that if you want to do this at the generic server level, this sounds 
very inefficient.  Sending this application-id as part of the URL for 
instance (or in a cookie), would be much more efficient, because then 
the server would not need to parse the request body.
5) Even so, to do this at the HTTP server level, would require the 
server to keep a table of applications to monitor, with counters for 
each application and possibly each client, and for each request 
determine which application it belongs to (if any), and some quite 
complex code to keep track and accept/refuse, "age" the counters and so on.

All in all, I believe that if you decide to go ahead with this, you 
should really make it part of each application individually, rather than 
trying to do this at the server level.  And if I was you, I'd also 
wonder if the expected benefits of doing this, would not be completely 
negated by the additional overhead of merely checking for the condition.

Maybe you need to re-think about your problem.
First, do you really need to limit the rate ?  Do you have any previous 
experience that tells you that this is necessary, or are you trying in 
advance to over-engineer a solution to a non-existent problem ?
Assuming you do need to, is it really per-application that you want to 
limit the rate, or per client ?
If per client, does each client have a different remote IP address ?
(if yes, then there are probably solutions available to limit the rate 
per IP; not necessarily in Apache itself however).
If per application, why not put each application on a separate server, 
and let it slow down if the rate of requests is "too high" (it will do 
that naturally, without any added code).  After all Apache httpd is 
free, you don't pay more for 10 copies than for one.

> On Fri, Jun 19, 2009 at 7:35 AM, Mohit Anchlia <>wrote:
>> We are using apache 2.2.6. We have a need to write a utility that
>> would throttle traffic based on the element of the content. We get
>> data from various client application that have application id assigned
>> to them. This application id is part of the text or xml content. What
>> we want is some utility that would prevent application request from
>> going further to application server if they exceed certain threshold.
>> So for eg: If application "1" is currently sending 100 transactions
>> per sec then we should have ability to say that present "turn away"
>> page to that application.
>> I am not sure how we can implement that in apache 2.2.6? It would be
>> really helpful if I could get some suggestions or if there are already
>> some tools available out there?

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message