Hi Ali, Kamailio's SIP message processing is accomplished by worker child processes which are forked when Kamailio starts. The number of these child processes is regulated by the 'children' core parameter: http://www.kamailio.org/wiki/cookbooks/4.3.x/core#children Any database operation is going to block one of these worker processes until it returns. It's not difficult to imagine 200-300 CPS clogging up the workers with database queries constantly, during which time no incoming SIP messages will be processed, as there is no process available to consume them. Worse yet, the dropped requests will cause retransmissions, adding to the deluge of messages experienced by Kamailio. Anyway, if your number of 'children' is very small, you may consider increasing it as the most immediate solution to your problem. Due to the high-performance interprocess communication architecture, it is not viable to have a large number of these child processes. There is some disagreement as to where the useful limit lies, but it tends to hover around the number of available CPU cores ('nproc'). Our experience with high-throughput testing suggests that having a number of children greater than the number of "CPUs" in /proc/cpuinfo has diminishing returns. Ultimately, however, the architecture is what it is. Handling high-CPS traffic through Kamailio is an art and a science. Some suggestions: 1. Reduce the latency of your database queries still further; 2. Use a caching layer like memcached or Redis to reduce database load; 3. Take advantage of Kamailio's asynchronous processing features: http://kamailio.org/docs/modules/4.3.x/modules/async.html #3 involves moving call processing out of the SIP worker processes and into another, separate thread pool, leaving the SIP worker processes free to process more messages. -- Alex On 07/28/2015 01:40 PM, Ali Taher wrote: -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/