The development branch has a new feature that allow setting number of worker processes to handle received traffic per listen socket.
So far there were global parameters that were applied to all sockets (e.g., ‘children’ value set the number of workers for all udp sockets). So far each UDP and SCTP socket had its own pool of workers (e.g., children=4 and 2 udp sockets resulted in 8 processes), while for TCP and TLS was a single pool of workers (e.g., having children (or tcp_children) set 8, resulted in 8 processes no matter how many TCP/TLS sockets).
The new features is based on using a new config parameter, named “socket_workers“, before a “listen” parameter. The value of “socket_workers” will overwrite the value of appropriate “*children” parameter. For UDP and SCTP will result in creating a number of “socket_workers” processes. For TCP and TLS will add an extra set of “socket_workers” processes, that will handle traffic only on those specific sockets.
The value of “socket_workers” is reset with the next listen socket added. If “socket_workers” is not set, the value of “*children” parameter is used in backward compatible fashion.
Some typical scenarios where this feature may become handy:
- set a lower number for loopback or internal/replication sockets, as the traffic there is low (e.g, maybe for keepalive monitoring on loopback, or it is only REGISTER requests replication done over the replication sockets)
- set a dedicated group of tcp/tls workers for handling HTTP/XMLRPC/XCAP traffic – handling such traffic may be time consuming, in this way you avoid delays on routing SIP over TCP/TLS
- fine tune the number of over all forked processes by a SIP server instance, thus controlling better the resources used from the physical server (e.g., overall private memory used by sip server is a matter of how many forked processes are there)
You can see details about the new parameter and examples on the wiki page: