I’ve had issues with cpp and just to get more throughput I had to increase
the size of the udp queue. It is also true that the cps was ten times
higher.
In the end, is very simple: if most of the time the udp queue is empty and
dropped packets are observed, then the size of the udp queue is too small.
Any other scenario must be handled differently.
-ovidiu
On Sat, Mar 23, 2024 at 17:49 Alex Balashov via sr-users <
sr-users(a)lists.kamailio.org> wrote:
On Mar 23, 2024, at 5:19 PM, Ovidiu Sas
<osas(a)voipembedded.com> wrote:
But the CPU is not the limiting factor.
We can agree on that, at least. :-)
Back to the funnel analogy: you have a big bottle
and you are using a
small funnel. That will not work well. If you use a bigger
funnel with the
same bottle (the bigger funnel must fit the bottle), than you can handle
more liquid.
If the funnel is too big for the bottle, then you
are spilling out and
this is the scenario that you are referring to.
I'm not sure how far this bottle metaphor works, because water falls into
the bottle at a constant rate and at a constant acceleration (force of
gravity), notwithstanding the moderating effect of funnel shape or other
geometric irregularities.
I think in the real world, we are dealing with a situation where water
falls into the bottle (through the bottle?) at different speeds, so most
limits are related to that flow and not to funnel or bottle size.
Or to say it differently: under most typical Kamailio workloads, which are
I/O-bound, a single Kamailio process (bottle) can handle a certain amount
of messages per second. You can't really make it handle more messages than
it does without tweaking the nature of the workload. Assuming the workload
is held constant, the only way to get more messages through the system is
to have more worker processes, or bottles if you like, which has its own
performance implications and limits (locking and CPU contention).
Consequently, there's a certain throughput-maximising amount of bottles
for a given workload that is neither so low as to under-utilise available
resources, nor so high as to degrade the overall throughput from fighting
for CPU, big locks over shared resources, overwhelming I/O dependencies
(e.g. databases with queries), etc. The main input variable is the number
of bottles itself.
The size of the funnel isn't really relevant. If there are enough bottles
and water goes into them at sufficient velocity, bigger funnels won't help.
If the velocity is not sufficient or there aren't enough bottles, funnels
of any size will just back up and overflow.
About the only scenario where the funnel matters is the one you pointed
out previously, where the inflow is highly irregular, is modally moderate,
and only momentarily bursts to high volumes.
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://evaristesys.com
Tel: +1-706-510-6800
__________________________________________________________
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: