Thanks, Daniel. So, does this mean that the module "reserves" a
"workers" number of common async_workers for its exclusive use? Or do those
async_workers just receive whatever they are sent from any number of modules? In that
case, what exactly is the role of the "workers" parameter? To limit the number
of async_workers to which the module will send requests?
On 24 October 2014 09:15:19 GMT-04:00, Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
On 23/10/14 04:03, Alex Balashov wrote:
Also, what is the point of core async_workers
setting versus the
'workers' modparam to async? Are they supposed to equal each other?
Does one override the other?
async_workers from core are common for all modules, being a decision
not
to have each module that wants async operations to create its own pool
of processes. The workers defined by async module are only for that
module and used only by async_route() and async_sleep().
The implementation is also different, the async module workers are more
like timer processes (because both of async_route() and async_sleep()
need to sleep some interval of time). The module itself keeps the lists
of tasks in a structure optimized for timer execution. Each of this
async module workers check from time to time to see if there is a task
to be executed, executes what matches the time, then sleeps again for
100ms (iirc), then checks again...
The async_workers from core were designed to receive the job
immediately. Because of that, there is an interprocess communication
based on sockets in memory. The async workers are listening on them, so
once a sip worker sends the task to them, an async worker will receive
it.
Hopefully I was able to explain it enough to understand what happens
behind.
Cheers,
Daniel
On 10/22/2014 09:36 PM, Alex Balashov 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?
>>
>
>
--
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: