[Freeswitch-users] Tuning Up Freeswitch
Antonio Teixeira
eagle.antonio at gmail.com
Mon Apr 25 21:53:44 MSD 2011
Humm What about this one.
http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_sched_hangup
and / or
there is also a possibility to hangup if you do not recveive any media (RTP)
just be careful with Voice Activation.
2011/4/25 François Delawarde <fdelawarde at wirelessmundi.com>
> Thanks Antonio, I'm already using that along with iptables rate
> limiting. It fits my needs but I need to run tests every time I install
> FS in a new hardware to find the optimal values.
>
> It's good enough for me, but I was just wondering if there was anything
> more automatic like some timer that could drop the call if it takes too
> long to process.
>
> It could also be useful for stalled DB connections or similar endless
> loops in some badly coded IVR applications.
>
> François.
>
>
> On Mon, 2011-04-25 at 10:05 +0100, Antonio Teixeira wrote:
> > Good Morning.
> >
> > @ Steven,
> > Thanks for the idea i will make a prototype in Python , and will send
> > you guysthe performance data when i have it.
> >
> > @ François
> >
> > You probably want this.
> > http://wiki.freeswitch.org/wiki/XML_Switch_Configuration
> >
> > 'sessions-per-second' - throttling mechanism, the switch will only
> > create this many channels at most, per second.
> >
> >
> >
> > 2011/4/25 François Delawarde <fdelawarde at wirelessmundi.com>
> > I also experienced a huge delay issue when attacked by mister
> > "friendly-scanner". The machine was not overloaded and call
> > setup was
> > working well but with a 10-20 seconds delay. Note that the
> > delay was
> > only with SIP answers, and once RTP was setup the audio was
> > perfect.
> >
> > Following advices from http://wiki.freeswitch.org/wiki/QoS
> > solved it in
> > my case. Is there a mechanism in FS that could detect huge
> > call setup
> > delay and simply reject calls?
> >
> > François.
> >
> >
> >
> >
> > On Sat, 2011-04-23 at 14:46 +0100, Steven Ayre wrote:
> > > 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 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
> > > > >>>
> > > > >>>
> > > > >>> --
> > > > >>> 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 at xpirio.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
> > > > >>
> > > > >>
> > > >
> > _______________________________________________
> > > > >> 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
> > > > >
> > > > >
> > > > > --
> > > > > 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 at xpirio.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
> > > > >
> > > >
> > > >
> > _______________________________________________
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > _______________________________________________
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > _______________________________________________
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > > >
> > > _______________________________________________
> > > 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
> >
> >
> >
> > _______________________________________________
> > 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
> >
> >
> > _______________________________________________
> > 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
>
>
>
> _______________________________________________
> 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/20110425/bd604703/attachment-0001.html
More information about the FreeSWITCH-users
mailing list