[OpenSIPS-Users] dispatcher with t_relay performance
Aqs Younas
aqsyounas at gmail.com
Mon Mar 7 21:14:41 CET 2016
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20160308/1d1b2d1b/attachment-0001.htm>
More information about the Users
mailing list