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@lists.kamailio.org> wrote:

> On Mar 23, 2024, at 5:19 PM, Ovidiu Sas <osas@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@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe: