Limit the RPS (requests per second) per REST resource

[Jaime]

We have prepared a REST SOA platform and we would like to restrict the
amount of requests per second (RPS) for each provided REST resource.
But how to calculate the RPS in a scalable platform?
I'm a newbie with redis and I found it very interesting for other
architecture issues but, could redis help me calculating the current
RPS of a resource? My first idea was to create a different list per
resource, where each request would be appended to the appropriate list
with an expiration of 1 second, and the RPS would be calculated with
LLEN command. However, the expiration is applied to a key not to an
element of a list. So this approach is not valid.
Do you have any idea how to calculate the RPS with redis?
Thanks in advance,
Jaime

[Sergei Tulentsev]

Do you need to calculate total RPS, for the whole system?

In this case, another approach would be to store a hash for each second where keys will be your resource names and values - access counts.
When new request arrives, you just do
hincrby "rps_201104091858", "my_resource", 1

This way, each hash will hold a second worth of data. Easy to expire/delete.

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To post to this group, send email to redi...@googlegroups.com.
To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.

--
Best regards,
Sergei Tulentsev

[Jaime]

Thanks Sergei,
Very simple approach and valid for my project. the not automatic thing
is to delete the past RPS. Perhaps it's better to execute
hdel <key>
when the timestamps (or second) changes instead of checking if the key
exists to add the expiration time.
Thank,
Jaime

[Dvir Volk]

you can check the return code of hincrby, and if it's 1 (meaning it's the first request for this second), delete the previous key.

if you want some backlog of rps, you can push the new second value onto a list, pop the other side of the list, and delete this hash.

Jaime

[Sergei Tulentsev]

Instead of deleting previous key, one can set expiration date for the current key. Let's say, 10 seconds. This way, there will always be 10 last seconds of data :-)

[Dvir Volk]

On Sun, Apr 10, 2011 at 8:25 PM, Sergei Tulentsev <sergei.t...@gmail.com> wrote:

Instead of deleting previous key, one can set expiration date for the current key.

this has 2 problems:

1. redis does lazy expiration, or rather semi lazy expiration. you'll have much much more than 10 seconds worth of expired data in your db if you don't touch old records.

2. "touching" a key before it expires means you reset the expiration. meaning you have to either re-set expiration on each increment, or watch for a second change, in which case you can just go ahead and delete the oldest unwanted key.

[Sergei Tulentsev]

Yes, you're right. Forgot about expiration reset.