It all depends on the hardware, but I noticed that after you pass 3-4k cps
you run into this kind of issues.
- ovidiu
On Sat, Mar 23, 2024 at 22:11 Alex Balashov via sr-users <
sr-users@lists.kamailio.org> wrote:
>
> > On Mar 23, 2024, at 9:30 PM, Ovidiu Sas wrote:
> >
> > In the end, we agree
> On Mar 23, 2024, at 9:30 PM, Ovidiu Sas wrote:
>
> In the end, we agree with each other and my feeling is that we are repeating
> the same concept.
Yeah, I think that's mostly right.
> In most of my deployments I don’t need to mess with the udp queue size.
> For high cps traffic, from my ex
The OP didn’t provide any additional info. Maybe he’s doing db operations.
Maybe he’s running something else on the server.
The traffic can be generally ok and then the OS is doing something weird or
some other application is doing something weird that can affect kamailio
for a short period of time
> On Mar 23, 2024, at 7:29 PM, Ovidiu Sas via sr-users
> wrote:
>
> Because you have dropped packets.
> The queue it’s empty most of the time and if is full for a few milliseconds
> and that’s the moment when you experience dropped packets.
Totally fair. Just wondering if that's what we're d
Because you have dropped packets.
The queue it’s empty most of the time and if is full for a few milliseconds
and that’s the moment when you experience dropped packets.
On Sat, Mar 23, 2024 at 19:23 Sergiu Pojoga via sr-users <
sr-users@lists.kamailio.org> wrote:
> > if most of the time the udp
Things could cascade due to retransmission.
It all depends on how much the system is loaded and the type of the traffic
and message handling in kamailio.
Sometimes the system recovers and works ok for a while until the next burst.
-ovidiu
On Sat, Mar 23, 2024 at 18:28 Alex Balashov via sr-users <
> On Mar 23, 2024, at 7:19 PM, Ovidiu Sas wrote:
>
> Things could cascade due to retransmission.
> It all depends on how much the system is loaded and the type of the traffic
> and message handling in kamailio.
> Sometimes the system recovers and works ok for a while until the next burst.
Some
> 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.
Hmm.. why would you need to increase the queue size if nothing gets queued
up?
On Sat, Mar 23, 2024 at 6:38 PM Alex Balashov via sr-users <
sr-users@lists.kamailio.org> wro
> On Mar 23, 2024, at 6:05 PM, Ovidiu Sas wrote:
>
> 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.
But would that happen with a sipp load test, once the threshold of dropped
requests is observed?
--
Alex Balashov
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 sm
> On Mar 23, 2024, at 5:19 PM, Ovidiu Sas 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
> On Mar 23, 2024, at 5:14 PM, Ovidiu Sas wrote:
>
> But if you are dealing with network jitter and several clients pumping
> traffic at different rates, for a short period of time all the workers will
> be busy while new SIP messages will pile up and the default queue will not be
> able to h
But the CPU is not the limiting factor.
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 fo
That will happen only if your CPUs are already maxed out.
Under ideal conditions, the default should work fine. But if you are
dealing with network jitter and several clients pumping traffic at
different rates, for a short period of time all the workers will be busy
while new SIP messages will pile
Fair, but when have you found CPU to be the limiting factor in Kamailio's
throughput? Kamailio's workload isn't really computational / CPU-bound. It's
closer to something like Node; it's an I/O multiplexer.
> On Mar 23, 2024, at 4:53 PM, Fred Posner wrote:
>
> That could be one scenario. But w
That could be one scenario. But when I’ve seen there being more than enough CPU
it has been there’s a more for 2MB worth of traffic and the OS is making an
issue that is easily solved by letting the system handle more traffic.
It’s a bottleneck before kamailio.
The analogy would be a funnel.
Sure, but if you're blowing through the default, that means you're not
consistently coping with the load due to some other factors. Does it not follow
that enlarging the queue will just give you more backlog without increasing
throughput?
-- Alex
> On Mar 23, 2024, at 1:54 PM, Fred Posner wro
The default queue I believe is about 2MB. Not very hard to exceed that queue
while still having a good amount of CPU/processor available.
-- Fred Posner
Sent from mobile
Phone: +1 (352) 664-3733
qxork.com
> On Mar 23, 2024, at 11:47 AM, Alex Balashov via sr-users
> wrote:
>
>
>> On Mar 2
> On Mar 22, 2024, at 10:21 PM, Ovidiu Sas wrote:
>
> The default udp queue length is not enough for high cps.
That's interesting. I'm not necessarily saying you're wrong, but I'd be curious
to know more about what informs this theory.
--
Alex Balashov
Principal Consultant
Evariste Systems L
19 matches
Mail list logo
