[Freeswitch-users] XML_CURL max connection limit

Wed Jun 12 15:15:42 MSD 2013

This sounds quite interesting.. From my own benchmarks, I've seen that IVRs
applications can be quite stressful on the server.

Have you checked to see if there is a CPU util spike or context switching
spike during these tests? Perhaps you are hitting the floor limit of what
your CPU is capable of?

Do you have CPU graphs? If not, can you enable them and try again?

Cal

On Wed, Jun 12, 2013 at 10:21 AM, Muhammad Shahzad <shaheryarkh at gmail.com>wrote:

> You are right. After many improvements and modifications to dail plan,
> removing unnecessary modules and using Ngnix web server, things are much
> better now. Except that directory information is fetched 3 times per call
> and there are overall 4 HTTP hits in a single call (3 for user + 1 for dial
> plan).
>
> Since Monday, we have started analyzing the results of load test,
> specially looking into packet traces, voicemail recordings and so on. We
> observed a strange thing, although we were able to test 1536 concurrent
> calls (the limit we deliberately put in switch.xml.conf) at up to 64 calls
> per second rate. But there is strange and unexplained delay in starting RTP
> from FS side.
>
> FS plays an IVR in early media state, then answers the call to directly
> start recording voicemail. The problem is if call rate is under 25 CPS,
> everything works fine. At 25 CPS there is minor delay in starting RTP in
> early media state. This delay is negligible after processing few hundred
> thousand calls but after about 1.2 million calls the delay has creeps up to
> about 1.2 seconds. After 30 CPS this delay is significantly increases to 2
> second after around 400 calls had done. At 50 CPS its ~3 second and after
> 60 CPS its around 4 seconds. Interesting thing is the delay is ONLY in
> starting playing IVR in early media state, once the IVR starts playing
> everything works perfectly fine. No call fails, but this delay would be
> annoying for anyone using the servers with over 30 CPS.
>
> Just to let you know, we checked everything, system resources, bandwidth
> usage, IVR file formats etc. all seems to be fine. We even tested with
> various FS start up options, e.g. -rp -nosql -nonat etc. etc. Nothing seems
> to have any impact on the results.
>
> I have run of out of possible explanations, so calling you guys for help.
>
> Thank you.
>
>
>
>
> On Fri, Jun 7, 2013 at 5:20 PM, Michael Jerris <mike at jerris.com> wrote:
>
>> I would need to see the specifics of your dialplan, but I suspect you
>> have some transfers or execute extension that are causing it to re-enter
>> dialplan.  Are you sure on all the others that they are making the exact
>> same requests?  Details here will be necessary to understand exactly what
>> is going on..
>>
>> Mike
>>
>> On Jun 7, 2013, at 4:07 AM, Muhammad Shahzad <shaheryarkh at gmail.com>
>> wrote:
>>
>> Guy, after detailed analysis i can confirm it was an Apache issue, and
>> changing Apache configuration changes the concurrent call limit. However,
>> one thing i observed about xml curl is that it makes several request with
>> same parameters per call. Even if we have no calls running on server, as
>> well as as Apache is completely free. I can see FS makes at least
>>
>> 1). 3 hits for dialplan.
>> 2). 2 hits for directory.
>> 3). 4 hits for voicemail.
>> 4). 3 hits for ivr.
>> 5). 2 hits for sofia.
>> and so on..
>>
>> While ideally only one hit should be sufficient to get all these
>> configurations. What is the point of making all these redundant hits? We
>> have roughly 15 - 20 hits made per call, which is huge and causes
>> significant load on Apache.
>>
>> Both Apache and FS are running on dedicated machines and connected over
>> Gigabit Ethernet with zero packet loss, so i doubt these hits are
>> "re-transmission".
>>
>> Thank you.
>>
>>
>>
>>
>> On Thu, Jun 6, 2013 at 1:24 AM, Muhammad Shahzad <shaheryarkh at gmail.com>wrote:
>>
>>> Yes, its a feature, i know. I was just looking at how this feature was
>>> tested, as mentioned in its logs,
>>>
>>> 2010-01-04 15:01:51.945020 [INFO] mod_dialplan_xml.c:408 Processing
>>> 21653XXXXX->121637XXXXX in context termination
>>> 2010-01-04 15:01:52.054466 [ERR] mod_xml_curl.c:310 Received HTTP error
>>> 0 trying to fetch http://192.168.0.2/gateway.php
>>> 2010-01-04 15:01:52.054545 [CONSOLE] mod_xml_curl.c:317 XML response is
>>> in /tmp/6632ebb1-d19f-4d51-a07e-ec2ce0387f83.tmp.xml
>>>
>>> Thank you.
>>>
>>>
>>>
>>>
>>> On Thu, Jun 6, 2013 at 12:48 AM, Michael Jerris <mike at jerris.com> wrote:
>>>
>>>> This is adding a feature to allow timeout to be set in ms instead of
>>>> seconds.  This is not a problem, its a feature, that was added a while ago.
>>>>  Until you can determine if the request is being sent for the one thats
>>>> failing, your not going to solve this issue.
>>>>
>>>> Mike
>>>>
>>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
>
> --
> 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
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130612/f757ad67/attachment.html 