[OpenSIPS-Users] dispatcher with t_relay performance

Mon Mar 7 23:41:18 CET 2016

May be i was unable to explain my question fully. I was thinking in other
direction.
Anyway Thank you.

On 8 March 2016 at 03:25, SamyGo <govoiper at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20160308/63256019/attachment.htm>