TL;DR; There's not enough information provided to give any real feedback. First, to address the elephant in the room, this is a bizarre business requirement: * 35% of invites should be handled by async_workers and 65% with be handled by main children Business requirements should concern scalability, security, technology stack (i.e. If their environment uses postgres, that could be a business requirement). The internals of *how* kamailio processes a message shouldn't be relevant to a business requirement (it may be necessary to achieve a business requirement, but that's not the same thing). With that said, sometimes requirements like this get stated and that's the world we live in. Next, It's not really clear from your description how you're using the async workers here. Consider the following psuedo kamalio config: #!KAMAILIO loadmodule "sl" children=64 async_worker=128 request_route { sl_send_reply("404", "Not Found"); } In that config, simply stating async_workers won't cause anything here to be handled by those workers. There's also the fact that the config itself bears massively on how many CPS can be handled. The config above, while not particularly useful, will handle way more than 1500 CPS (or more accurately requests per second). You state that "when I updated the data in database to not use anymore async workers", but what is changing in the database, etc? You can't really show two lines of your configuration and expect anyone to know where you have processing latency, etc. Finally, I'd point out that this is a very number of worker processes, and that children gets applied to every listener. You don't state what your private memory size is, but assuming that Kamailio starts on the loopback address and a single network interface as both TCP and UDP, you'd have 192 processes for your listeners (tcp workers are global instead of per listener, iirc), another 128 processes for your async workers, and about a dozen more default processes (main process, timers, etc). Assuming that you are using the default private memory allocation of 8 MB/process, that makes 2.8 GB for private memory alone. While that's not a massive amount of memory on a modern system, it's also likely you'd want to bump up that 8 MB setting, too. Regards, Kaufman ________________________________ From: elhar.mohamed--- via sr-users <sr-users(a)lists.kamailio.org> Sent: Friday, August 16, 2024 4:24 AM To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org> Cc: elhar.mohamed(a)gmail.com <elhar.mohamed(a)gmail.com> Subject: [SR-Users] low performance with udp_children and async_workers CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, Based on business requirements, 35% of invites should be handled by async_workers and 65% with be handled by main children. The target is 1500cps. I'm using the following conf : children=64 async_worker=128 when doing performance tests using SIPp, I figured out the 1500cps is well supported by the conf above, but when I updated the data in database to not use anymore async workers, the cps is getting decreased and it was between 200 and 500. This a client requirements is to be able to enable/disable feature that needs to be handled by async workers. Could you please help me on this? Thanks in advance __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: