ESL would be best as you can offload the processing to another server - potentially a load balanced cluster.

Steve on iPhone

On 23 Apr 2011, at 08:51, Antonio Teixeira <eagle.antonio@gmail.com> wrote:

Hello Michael & The rest.

What i'm trying to find is the solution with the highest performance for IVR Applications. And squeezing the last bit of performance out of freeswitch is a needed path specially on a industry that does second by second billing :P
i'm going to do some performance testing with Lua , ESL And Mod Curl and of course python and measure some performance data and will post it later.

A/T


2011/4/22 Michael Collins <msc@freeswitch.org>
You can definitely use the event socket. Heck, you can even use Python if you want to. The dev team wrote ESL specifically for cases like these - where you want to control FS externally. ESL beats the pants off AGI scripts. It gives you complete control over the system.

That all being said, you can do all sorts of stuff with Lua dialplan scripts. Check out chapter 7 of the FreeSWITCH book for some nice examples. Lua is lightweight and easy to learn. It's a good alternative for many cases. Check it out...

-MC


On Fri, Apr 22, 2011 at 12:39 PM, Antonio Teixeira <eagle.antonio@gmail.com> wrote:
Well i totally agree with the Dev team decision , it would be impossible for a DEV team to "get it right" in all the distros that's why i started this post.

But we also need to take into consideration that we are talking about IVR Processing ,  not auto-attendants or simply call pass trough.
This means heavy use of TTS / ASR , Database Logic and Scripts , GetDigits and the works.

I use python alot , but i think the mod_python is not the best tool for this job i admit that , that's why im currently looking for other solutions.
I'm thinking in using mod_socket , but that scares me ( letś say bad experiences with Asterisk AGI) Or Mod Curl

The main problem is that some IVR are extremely complex , like questionnaires , etc.

It would be great if we could mod_event_zmq to control the calls <330.gif>

Just to Sum it UP so far , so i can later add it to the wiki.

Use Cent OS 64.
Use tmpfs for all the databases.

Thank you all for helping and Happy Eastern.
António Teixeira





2011/4/22 Michael Collins <msc@freeswitch.org>
FreeSWITCH runs well on many platforms. However, the devs are painfully aware that bleeding edge distros have bleeding edge gcc compilers and other interesting issues. That being said, CentOS 5.x is "stable" in that it's old and boring, therefore it has the least amount of drama. OTOH, some of our users have been having great success with Arch Linux (IRC:bougeyman) and FS, even though Arch uses very recent kernels.

Bottom line: if you know what you're doing then you can probably run FS anywhere. If you don't know what you're doing then stick with CentOS 5.x or Debian Lenny until you do. (I run then both with zero issues, compiling latest git each day.)

-MC


On Fri, Apr 22, 2011 at 10:03 AM, curriegrad2004 <curriegrad2004@gmail.com> wrote:
Freeswitch is targeted for CentOS 5.3, which in my opinion quite short
sighted for the developers to do this. However with the limited size
of developers and testers, I'm afraid there's not much platforms we
can throughly test and actually say "okay, FS will run flawlessly on X
distro"

However you can always try messing with the CFLAG's mtune option and
see what it produces for you...

2011/4/22 Christian Löschenkohl <christian.loeschenkohl@xpirio.com>:
> hi
>
> if you refer to my e-mail
>
> yes, we do use tmpfs on both variants but
> - delays occur with concurrent calls > 80-100
> - cps is limited to 5-10 on debian, with centos 30 cps and more are no problem at all
>
> also cpu load, stability and overall performace have been much better since using centos
>
> i just found out for me that debian works not as good for me as centos does.
> btw. everywhere else debian is 1st choice (desktop, lamp, db etc.)
>
> br
>
>
> On 2011-04-21 23:04, Jay Binks wrote:
>
>> I have no such problems on debian .
>>
>> I use debian 5 with 2.6.18 kernel which is what Is recommended
>>
>> Are you using tmpfs ??
>>
>> Jay
>>
>>
>>
>> On 22/04/2011, at 3:26 AM, Christian Löschenkohl<christian.loeschenkohl@xpirio.com>  wrote:
>>
>>> hi
>>>
>>> we did use debian too and had such performance issues (sip packet delays, low cps).
>>> after using centos 64bit (as advised by the devs) all performance problems are gone.
>>>
>>> br
>>>
>>> On 2011-04-21 18:24, Antonio Teixeira wrote:
>>>
>>>> Hello List.
>>>>
>>>> I'm currently integrating an IVR in python together with freeswitch using mod_python and ESL and my life has been well until ...
>>>> The flow of calls went over 80 simultaneous calls.
>>>> Now freeswitch starts sending packets with huge delays ( even when establishing the call , mainly the 200 ) and firing up the IVR with tons of delay up to 20 seconds.
>>>>
>>>> So i searched the wiki forums and mailing list:
>>>>
>>>> Put freeswitch on a diet , trimmed modules.conf
>>>> Played with the ulimit stuff.
>>>> Played with the IVRS to reduce load to a minimum and i was able to squeeze more 5 calls of performance.
>>>>
>>>> The problem is :
>>>>
>>>> Top shows
>>>> top - 16:14:33 up 35 days,  8:15,  3 users,  load average: 1.92, 1.76, 1.78
>>>> Tasks: 133 total,   1 running, 132 sleeping,   0 stopped,   0 zombie
>>>> Cpu(s):  1.4%us,  3.3%sy,  0.0%ni, 94.6%id,  0.0%wa,  0.3%hi,  0.5%si,  0.0%st
>>>> Mem:   8193336k total,  1639156k used,  6554180k free,   177208k buffers
>>>> Swap: 19534904k total,        0k used, 19534904k free,  1062272k cached
>>>>
>>>>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>> 31361 yadayada      20   0  716m 164m 9628 S   73  2.1 155:17.85 freeswitch
>>>>
>>>> Freeswitch goes up to 150 % and puff there goes the MOS down to 0.
>>>>
>>>>
>>>> Some basic System Info :
>>>> Debian 6.0 ( i heard the timming module is affected by Debian , but if the CPU % gets lower than 95% everything will be more stable)
>>>> Python 2.5
>>>>
>>>> 2 x Intel(R) Xeon(R) CPU           E5506  @ 2.13GHz
>>>> 8 GB of Ram
>>>>
>>>> as you can see 94 % of the "Cpu Power" is sleeping :\
>>>>
>>>>
>>>> It appears freeswitch is only capable of using let's say "one cpu"/thread ??
>>>> Do you guys recommend simply starting more instances or redoing the IVR stuff.
>>>>
>>>>
>>>> Hope you guys can help me out.
>>>>
>>>> Thanks
>>>> António Teixeira
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> FreeSWITCH-users mailing list
>>>> FreeSWITCH-users@lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>> http://www.freeswitch.org
>>>
>>>
>>> --
>>> Ing. Christian Löschenkohl
>>> Technische Leitung, Forschung&  Entwicklung VoIP
>>>
>>> xpirio
>>> Telekommunikation&  Service GmbH
>>> Lakeside B04
>>> 9020 Klagenfurt
>>> Austria
>>>
>>> T  +43 5 77 11 - 1000
>>> F  +43 5 77 11 - 1002
>>> E  christian.loeschenkohl@xpirio.com
>>>
>>> _______________________________________________
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users@lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users@lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>
>
> --
> Ing. Christian Löschenkohl
> Technische Leitung, Forschung & Entwicklung VoIP
>
> xpirio
> Telekommunikation & Service GmbH
> Lakeside B04
> 9020 Klagenfurt
> Austria
>
> T  +43 5 77 11 - 1000
> F  +43 5 77 11 - 1002
> E  christian.loeschenkohl@xpirio.com
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org



_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org



_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org