[SR-Users] async workers

Alex Balashov abalashov at evaristesys.com
Fri Oct 24 16:36:43 CEST 2014


Vitaliy, 

The argument against more workers holds that the specific interprocess communication used by them causes one to reach the point of diminishing returns rather quickly, due to contention and locking. In many applications, one can create dozens of hundreds of workers in such a situation, and for precisely the reason you mention. In my experience, 2*num_cpus is the absolute maximum in Kamailio before one starts to lose more in contention than one gains from the throughout of an additional worker. 

Actual results vary and depend on the anatomy of the workload (i.e. how much data is operated upon in shared memory, amongst the processes, versus package memory). But in general, the number of workers Kamailio can have is quite low. 

For example, I have a quad-core CPU. I can get about 400-500 CPS with 8 children. If I increase the number of children to 16, it plummets to 200 or less. When I increase further, throughout falls further. 


On 24 October 2014 10:30:49 GMT-04:00, Vitaliy Aleksandrov <vitalik.voip at gmail.com> wrote:
>
>>>> Hi,
>>>>
>>>> What is the practical limit to the number of async worker
>processes?
>>>>
>>>> With SIP child processes, it seems to be about the number of
>available
>>>> CPUs in /proc/cpuinfo. After that--at least, per my testing--one
>>>> begins to hit the point of diminishing returns, presumably due to
>SHM
>>>> IPC and synchronisation issues.
>>>>
>>>> Is the restriction similar in the async execution context?
>>> no specific restriction. Also, I haven't seen any degradation when
>using
>>> more sip worker processes that cpus, which I do have always (at
>least 2
>>> per CPU), because a worker can do quite a lot of I/O.
>>
>> I have seen such degradation, at least in my VM testing environment.
>I 
>> find that I get the highest CPS (e.g. with sipp) with the smallest 
>> number of workers.
>>
>> Actually, I get as good throughput with 4 workers (in an 8 "CPU" 
>> scenario on a quad-core processor) as I do with 8! Increasing beyond
>8 
>> leads to diminishing returns.
>>
>With real traffic some of workers can be busy on blocking operations 
>such as database queries or host name resolution. So I prefer to add 
>more workers to not get in situation when all my workers are blocked by
>
>something.
>
>_______________________________________________
>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



More information about the sr-users mailing list