[SR-Users] best way to cope with peaks in traffic

davy van de moere davy.van.de.moere at gmail.com
Mon Oct 27 11:37:32 CET 2014


Hey Alex,

thanks for your prompt insights! This info will have saved me quite some
mistakes ;)

thx!

2014-10-26 20:28 GMT+01:00 Alex Balashov <abalashov at evaristesys.com>:

> If you want to rate-limit traffic below the throughout thresholds of the
> children, look at the pipelimit module. It would obviate the need for
> manual htable statekeeping.
>
>
> On 26 October 2014 15:23:27 GMT-04:00, Alex Balashov <
> abalashov at evaristesys.com> wrote:
>>
>> Workers process SIP messages, which means both requests and replies. So,
>> you can't use request-oriented tracking to make that decision.
>>
>> The answers to your question are basically:
>>
>> 1. Keep your call processing as fast and light as possible.
>>
>> 2. Use async methods.
>>
>> Async methods only help so much, due to the strict timing tolerances of
>> SIP, and real-time, delay-sensitive communication in general. The
>> fundamental answer is basically #1--incur as little delay as possible.
>>
>>
>> On 26 October 2014 14:33:43 GMT-04:00, davy van de moere <davy.van.de.
>> moere at gmail.com> wrote:
>>>
>>> Gents,
>>>
>>> assuming we don't use async methods (I know, it's against fashion),
>>> eventually you'll end up in having some bottlenecks in your config...
>>>
>>> Now thanks to a lot of children you can easily work around this, a
>>> maximum of 32 children gives you already quite something, and if you use
>>> the dispatcher, you can ramp that up to quite some capacity. ;)
>>>
>>> Now, there are moments where still limits are passed, so what would be
>>> the best way to keep your system healthy?
>>>
>>> I was thinking in the direction of using a hashtable value or $var to
>>> keep track of the children in use and e.g. if 31 children are used, refuse
>>> to process the 32th request (assuming 32 children are setup).  Would this
>>> be a valid strategy? Or am I overthinking?
>>>
>>> Grtz,
>>>
>>> Davy
>>>
>>> ------------------------------
>>>
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>> --
>> Sent from my mobile, and thus lacking in the refinement one might expect
>> from a fully fledged keyboard.
>>
>> Alex Balashov - Principal
>> Evariste Systems LLC
>> 235 E Ponce de Leon Ave
>> Suite 106
>> Decatur, GA 30030
>> United States
>> Tel: +1-678-954-0671
>> Web: http://www.evaristesys.com/, http://www.alexbalashov.com
>>
>> ------------------------------
>>
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
> --
> Sent from my mobile, and thus lacking in the refinement one might expect
> from a fully fledged keyboard.
>
> Alex Balashov - Principal
> Evariste Systems LLC
> 235 E Ponce de Leon Ave
> Suite 106
> Decatur, GA 30030
> United States
> Tel: +1-678-954-0671
> Web: http://www.evaristesys.com/, http://www.alexbalashov.com
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20141027/db8213ec/attachment.html>


More information about the sr-users mailing list