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 <mohitanchlia@xxxxxxxxx>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:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|