[Freeswitch-users] XML_CURL max connection limit

[Steven Ayre]

Have you looked at how reliable your system's clock is?

http://wiki.freeswitch.org/wiki/Mod_commands#time_test
http://wiki.freeswitch.org/wiki/Mod_commands#timer_test<http://wiki.freeswitch.org/wiki/Mod_commands#time_test>

-Steve




On 12 June 2013 10:21, 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/3716ea4d/attachment.html