[Openstack-operators] Nova API rate limiting

Joshua Harlow harlowja at yahoo-inc.com
Fri Jun 28 21:48:19 UTC 2013


Agreed 100% once it hits the python layer, since python can't really scale
to well it will already cause your applications to start misbehaving.

Something in front of the api's (haproxy, apache, nginx, balancers...) can
handle it better.

Once it hits the wsgi layer, it just might be to late (especially when
overloaded).

On 6/27/13 6:16 PM, "Robert Collins" <robertc at robertcollins.net> wrote:

>On 28 June 2013 12:02, Joshua Harlow <harlowja at yahoo-inc.com> wrote:
>> Also note that the default rate limiting implementation is in memory.
>>
>> So if u are running nova in forking 'mode' then each fork will have its
>>own
>> copy of that rate limit information and thus the real rate limit will
>>be (N
>> x rate_limit) with N forks.
>>
>> At least I believe this is correct. So be careful with that, it would be
>> nice to have a better impl (maybe using turnstile?) as the default
>>someday.
>
>From a production perspective I'd much rather deal with overload
>holistically: e.g. by looking at mean and 95% time to service and
>delay in queue - rather than letting requests get deep into the wsgi
>stack (e.g. authenticated etc).
>
>Something like haproxy is designed to do this efficiently and at
>scale, for many thousands of requests/sec per proxy.
>
>-Rob
>
>-- 
>Robert Collins <rbtcollins at hp.com>
>Distinguished Technologist
>HP Cloud Services




More information about the OpenStack-operators mailing list