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 <[email protected]>
Sent: Friday, August 16, 2024 4:24 AM
To: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
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 [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
