computing request rate

[Peter]

Hi

I am not sure this is really directly c# related, but I am not sure the
best place to post.

I need to be able to determine the rate of requests to my
web-application. That is, how many requests per second I receive.

Actually it's a little more complicated, because I need to determine
the rate of requests per user. For example, user 1 is issuing requests
at 15.3 per second, user 2 at 32.8 per second and so on.

And further to this, my application can be "distributed". That is, it
can be running in multiple locations, but I need to accumulate the
request rate counts for all the locations.


Can anyone help me get started on this?


To start with I need a method for determining a request rate. I have a
method which does this (called Measure). I think this is ok - I call
this method on every request, to calculate a rate. But maybe this
should be averaged over a longer period? Is this neccessary and how can
I do this?

Another area I have trouble with is how to persist this data between
requests. Some sort of common cache available over http or tcp
(soap/webservice/wcf maybe?) - but what if two requests come close
together (or from different machines) - how do I control the updating
of the request rate so it is reliable?


public Info Measure(Info information)
{
information.LastTicks = information.ThisTicks;

long now = 0;
QueryPerformanceCounter(out now);
information.ThisTicks = now;

long diff = information.ThisTicks - information.LastTicks;

if (diff > 0)
{
information.RequestRate = ((double)freq) / diff;
}

return information;
}

public class Info
{
public long ThisTicks { get; set; }
public long LastTicks { get; set; }
public double RequestRate { get; set; }
}

Thanks,
Peter

--

 

[Fredo]

Does it need to be real time? Why not just parse the HTTP logs? They'll have
the requests along with a timestamp for each request. Then it's simply a
matter of parsing the log and calculating the request rate at various
intervals.

 

[Peter]

Does it need to be real time? Why not just parse the HTTP logs?
They'll have the requests along with a timestamp for each request.
Then it's simply a matter of parsing the log and calculating the
request rate at various intervals.

Thanks, yes it does need to be as "real time" as possible. I am trying
to use the information in a throttling scheme where I start to reject
requests if a particular user is issuing requests too often.

 

[Peter Duniho]

Thanks, yes it does need to be as "real time" as possible. I am trying
to use the information in a throttling scheme where I start to reject
requests if a particular user is issuing requests too often.

Do you have some existing mechanism for tracking per-client information?
If so, you should simply store the request-rate information there. If
not, you need to create one. The techniques for doing that wouldn't be
specific to tracking rates of requests

As far as the request-rate calculation goes, what you posted seems fine as
far as it goes (assuming "freq" is related to the performance counter
frequency...you didn't post the code that initializes that variable, so
there's no way for us to know for sure). You're calculating an
instantaneous rate, rather than an averaged rate. Whether that's
appropriate for your needs depends on your own specifications. We can't
answer that.

That said, it's not uncommon to do some kind of averaging to determine
rates. What kind of averaging to do would depend on what measure of
"rate" you want to use. But yes, doing some averaging could be
appropriate as well.

Pete