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 <mico...@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: http://www.evaristesys.com/, http://www.alexbalashov.com _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
