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 <mohitanch...@gmail.com>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-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
