[OpenSIPS-Users] load_balancer usage counter

Callum Guy callum.guy at x-on.co.uk
Mon Feb 5 11:09:22 UTC 2024


Yes, that is correct.

My apologies in advance for the half formed issue - my implementation
with multiple OpenSIPs instances in front of the freeswitches isn't
ideal for the module and I'm just looking for the best solution for
such a scenario. I'm happy to share more details if that's useful but
the main goal is to ensure that channels are used "somewhat" evenly as
a percentage of the maximum sessions reported by each freeswitch
instance.

On Mon, 5 Feb 2024 at 10:58, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
>
> Hi Callum,
>
> Just to be 100% sure I got this right - the exact issue you report here
> is also (in a more detailed way) reported in 3297 HG ticket, right ?
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>    https://www.opensips-solutions.com
>    https://www.siphub.com
>
> On 02.02.2024 16:53, Callum Guy wrote:
> > Hi Bogdan,
> >
> > Thanks for taking a look.
> >
> > I'm still working on this and was in the process of writing a second
> > issue to discuss my findings from looking at the module. In essence we
> > can see the profiles potentially being counted multiple times - both
> > in the max_load calculation (lb_update_max_loads) and then again in
> > the balancing code itself (get_dst_load).
> >
> > You are correct that I have multiple OpenSIPs in front of these
> > freeswitch instances. I operate separate registrars and SBCs and these
> > do not replicate data to each other. The main complication arises as I
> > am gradually releasing this onto a busy system - callers are currently
> > allocated to a specific freeswitch server using manually controlled
> > logic and am aiming to use the load balancer to automatically
> > distribute the calls, allowing instances to be easily added and
> > removed without reallocating callers to devices. As the vast majority
> > are not initially enrolled in the load balancer the calls are not
> > being counted and therefore the test accounts all have zero calls in
> > the profile and the call is being distributed to any instance rather
> > than the instance which has the most available channels
> > proportionally.
> >
> > I've just gone ahead and posted the issue
> > (https://github.com/OpenSIPS/opensips/issues/3297) as you've responded
> > - that might add confusion or clarity, I'm not sure yet!
> >
> > I think I need to take some more time to review the module and propose
> > a solution that will work for my scenario but I'm happy to share more
> > details of the setup if you are interested in helping me to find a
> > solution that would work for both me and the community.
> >
> > Many thanks,
> >
> > Callum
> >
> > On Fri, 2 Feb 2024 at 14:37, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
> >> Hi Callum,
> >>
> >> I can confirm the module increments its internal load with each call, so
> >> you are good to go. Still, I do not understand why using the FS
> >> heartbeat here? are the FS servers receiving calls from other
> >> destination than OpenSIPS too ?
> >>
> >> Regards,
> >>
> >> Bogdan-Andrei Iancu
> >>
> >> OpenSIPS Founder and Developer
> >>     https://www.opensips-solutions.com
> >>     https://www.siphub.com
> >>
> >> On 30.01.2024 16:27, Callum Guy wrote:
> >>> Hi All,
> >>>
> >>> I'm implementing the load_balancer module on a very busy system where
> >>> thousands of calls may arrive in a matter of seconds. The module is
> >>> configured to receive heartbeats every 1 second from many freeswitch
> >>> servers, I have this set as a low value to try and keep OpenSIPs up to
> >>> date with the real call load, as close to real time as possible.
> >>>
> >>> All servers exist in a single group "channels" to keep the initial
> >>> implementation simple. When I kick off the session I use lb_start(1,
> >>> "channels", "rs") and if that destination fails I use lb_is_started()
> >>> and lb_next() to select the next destination.
> >>>
> >>> With the high call rate I'm concerned that the load values acquired 1
> >>> second ago will be used for the entirety of the following second which
> >>> would likely lead to a highly imbalanced load. If 1000 calls arrive in
> >>> that second I need them spread evenly over the freeswitch servers
> >>> which can only happen if OpenSIPs is counting each call as its
> >>> allocated.
> >>>
> >>> My hope is that the module increments its counters each time a call is
> >>> allocated to a destination; however I have been unable to isolate the
> >>> line of code which performs this operation so I'm reaching out for
> >>> confirmation. I can see the module adding the dialogs to profiles and
> >>> that a separate lb_count_call() method is provided for counting calls
> >>> but I'm unclear on the exact usage although it certainly encourages me
> >>> that this counting is taking place somewhere.
> >>>
> >>> Thanks for reading,
> >>>
> >>> Callum
> >>>
>

-- 






*0333 332 0000  |  x-on.co.uk <https://www.x-on.co.uk>  | **  |  
**Practice Index Reviews <https://practiceindex.co.uk/gp/x-on>*

*Our new 
office address: 22 Riduna Park, Melton IP12 1QT.*

X-on
is a trading name 
of X-on Health Ltd a limited company registered in
England and Wales.

Registered Office : Glebe Farm, Down Street, Dummer, Basingstoke, 
Hampshire, England RG25 2AD. Company Registration No. 2578478.

The 
information in this e-mail is confidential and for use by the addressee(s)
only. If you are not the intended recipient, please notify X-on immediately 
on +44(0)333 332 0000 and delete the
message from your computer. If you are 
not a named addressee you must not use,
disclose, disseminate, distribute, 
copy, print or reply to this email. Views
or opinions expressed by an 
individual
within this email may not necessarily
reflect the views of X-on 
or its associated companies. Although X-on routinely
screens for viruses, 
addressees should scan this email and any attachments
for
viruses. X-on 
makes no representation or warranty as to the absence of viruses
in this 
email or any attachments.











More information about the Users mailing list