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: