[OpenSIPS-Users] dispatcher with t_relay performance

[SamyGo]

Hi Satesh,

So I'm not sure what you're talking about - did you post in mailing list
about the problem. Was it something that can't be done or has no answer to
it ? Were some other alterations tried to the approach ?

As far as I know even if you multi-home an opensips you can still
force_send_socket() and if it is not forced then Operating System tells the
correct interface to use to send packets out.  Right now I can only assume
things.

@Aqs, given your own experiences and engagement in the mailing list I don't
think there is any big thing to explain in there.

The First layer is nothing but a dispatcher loaded in it pointing to N
number of servers.
Take an example: http://www.opensips.org/Documentation/Tutorials-Redirect

Now modify it to use dispatcher,

request_route {
...
           if(!ds_select_dst("1","4")) {      /* See new version of
ds_select_dst(), there are partitions involved etc */
              sl_send_reply("503","Service Unavailable");
           }

           /* modify Contact Header... */

           sl_send_reply("302","Moved Temporarily");
}

And I think thats pretty much it, the Sender will get a 302, with a new
Contact header and then it is supposed to talk to that new server.
Again its the business logic and depends from usage to usage. This is not
the only way to increase capacity or efficiency. Sometimes UACs/UASs don't
like Redirecting and this method flops.

Regards,
sammy


On Mon, Mar 7, 2016 at 3:14 PM, Aqs Younas <aqsyounas at gmail.com> wrote:

> Hi, SamyGo
>
> I have seen many people doing two layer opensips setup. First layer as
> stateless dispatcher and other layer for business logic.
> I just wonder why not just one layer of opensips doing business logic. I
> am unable to understand this two layer concept.
>
> Can you explain this a bit.
>
> Thanks in advance.
>
>
> On 7 March 2016 at 20:35, SamyGo <govoiper at gmail.com> wrote:
>
>> Oh, I thought it was a typo, 200,000 CPS ! Well I'd say to not spend much
>> time thinking about t_relay() rather spend energy on designing an
>> architecture that can give you the flexibility and scalability options.
>>
>> For example:
>> A DNS SRV pointing to a layer of stateless dispatcher OpenSIPS. These
>> stateless OpenSIPS just don't care about any business logic just do a rough
>> load-balancing and "redirect" to the second layer OpenSIPS.
>> The second layer of OpenSIPS do the business logic and stay in call i.e
>> use t_relay()
>>
>> That is a simple example in which you can add as many OpenSIPS at both
>> layers to manage your 200K CPS.
>>
>> There could be way too many different ways of handling your 200K CPS
>> load, it all depends on your business logic, type of SIP requests and calls
>> etc, location of the end users/regions, methods to tweak your business
>> logic i.e use of caches and NoSQL DBs, and so much that only you may know
>> at this point.
>>
>> Please go through this link:
>> http://www.opensips.org/About/PerformanceTests to see results for
>> different types of configurations. However, do keep in mind that those
>> results may be done on older versions of OpenSIPS and you may want to
>> stress test your setup separately to know what are your capabilities.
>>
>> Regards,
>> Sammy
>>
>>
>>
>> On Mon, Mar 7, 2016 at 8:54 AM, Satish Patel <satish.txt at gmail.com>
>> wrote:
>>
>>> We have 200,000 CPS and more in future. Just worried about t_relay() and
>>> its performance. Any idea?
>>>
>>> --
>>> Sent from my iPhone
>>>
>>> On Mar 6, 2016, at 2:44 PM, SamyGo <govoiper at gmail.com> wrote:
>>>
>>> I'd ask you to read difference between Load_balancer and Dispatcher
>>> module. Dispatcher module is not an accurate measure but it is the only
>>> option when it comes to load balancing REGISTER requests.
>>>
>>> Dispatcher is hence very light weight as compared to Load Balancer. For
>>> a 200 CPS calls Load Balancer or Dispatcehr won't be putting any bigger
>>> impact relative to the business logic itself. For example doing alot of DB
>>> queries, engaging various other modules etc these things really define how
>>> light or heavy your system is going to be.
>>>
>>> Regards,
>>> Sammy
>>>
>>>
>>> On Sun, Mar 6, 2016 at 10:36 AM, Satish Patel <satish.txt at gmail.com>
>>> wrote:
>>>
>>>> Any thought on it???
>>>>
>>>> On Fri, Mar 4, 2016 at 1:30 PM, Satish Patel <satish.txt at gmail.com>
>>>> wrote:
>>>> > We have dispatcher and we are using very simple code block like
>>>> following
>>>> >
>>>> > if (method=="REGISTER" || method=="INVITE" ) {
>>>> >      ds_select_dst("1", "2");
>>>> >      t_relay();
>>>> >    }
>>>> >
>>>> > Does t_relay will keep all transaction in memory? and what will be the
>>>> > performance issue?  we have ~200k cps calls.. what will be the impact?
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20160307/dd036fa4/attachment.htm>