[Freeswitch-users] Tuning Up Freeswitch
François Delawarde
fdelawarde at wirelessmundi.com
Mon Apr 25 13:48:37 MSD 2011
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
More information about the FreeSWITCH-users
mailing list