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 < [email protected]> wrote: > > > On Mar 23, 2024, at 5:19 PM, Ovidiu Sas <[email protected]> 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 [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:
