24 Oct
2014
24 Oct
'14
8:13 a.m.
On 10/24/2014 09:07 AM, Daniel-Constantin Mierla wrote:
Hello,
On 23/10/14 03:36, Alex Balashov wrote:
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.
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
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.