[OpenSIPS-Users] MediaProxy behaviour on Heavy call volume.

[Adrian Georgescu]

The best optimization would be to make OpenSIPS core work asynchronous so that a request won't block the processing of new requests. Until this happens is little you can optimize if you want distributed infra with high cps. The lowest hanging fruit today to achieve highest CPS is to colocate all external components on the same LAN with OpenSIPS.

Adrian
  
On Apr 8, 2013, at 11:32 AM, SamyGo wrote:

> Hi AG,
> I understand your point, so in this matter we should not only consider the latency between dispatcher and relay but also consider the processing capability of both components as high CPS might require significant resources on relays as well.
> 
> Are there any particular areas which you can point out for me to optimize this?
> 
> Thanks
> Sammy
> 
> On Apr 7, 2013 6:40 PM, "Adrian Georgescu" <ag at ag-projects.com> wrote:
> As OpenSIPS core is not async, the whole chain of processing a message can cause this. Practically, summing up all RTT for all your database queries, DNS lookups, Radius requests, media reservations can cause this.
> 
> The farther away each component is the poorest the performance as that child cannot process any new packet until is done with the previous.
> 
> Adrian
> 
> On Apr 7, 2013, at 3:27 PM, SamyGo wrote:
> 
>> Hi Sir,
>> Yes, we've optimized our opensips to have enough shared memory as well as the number of children have been increased as well but this situation is still the same.
>> 
>> What I can logically think why this is happening is as follow:
>> 
>> 1- Media-relays are in another DC,
>> 2- Dispatcher queries relays to get the port info to update the SDP with
>> 
>> The delay or slowness of relays might be something causing overall queue length to shoot up.
>> 
>> Let me know what you think,
>> 
>> --
>> Sammy
>> 
>> 
>> 
>> On Sat, Apr 6, 2013 at 2:43 AM, Muhammad Shahzad <shaheryarkh at gmail.com> wrote:
>> Well, if you have very high CPS then typically need more opensips children processes to handle load. So you need to,
>> 
>> 1. increase no. of children.
>> 2. optimize per child and shared memory sizes.
>> 
>> BTW what does it has to do with media proxy as you are reporting SIP UDP port only gets hanged?
>> 
>> Thank you.
>> 
>> 
>> 
>> On Fri, Apr 5, 2013 at 8:42 PM, SamyGo <govoiper at gmail.com> wrote:
>> Hello,
>> 
>> I'm working with opensips with heavy CPS, recently I added mediaproxy-dispatcher on the server and couple of relays on different servers in different Data Center. Everything worked fine until we observed that opensips SIP UDP port 5060  got huge queued packets. 
>> 
>> That obviously impacts the call processing. I want to know if this is a usual behavior? or can this be treated/tuned ?  
>> 
>> Thanks,
>> Sammy
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
>> 
>> 
>> 
>> -- 
>> Mit freundlichen Grüßen
>> Muhammad Shahzad
>> -----------------------------------
>> CISCO Rich Media Communication Specialist (CRMCS)
>> CISCO Certified Network Associate (CCNA)
>> Cell: +49 176 99 83 10 85
>> MSN: shari_786pk at hotmail.com
>> Email: shaheryarkh at googlemail.com
>> 
>> _______________________________________________
>> 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/20130408/0480b941/attachment-0001.htm>