VoIP Mailing List Archives

[jbr at consiglia.dk]

I have made some load test, where an Asterisk server was controlled to make a high number of calls to a FreeSWITCH, which was registered on Asterisk. Each had its own server. The calls made to the FreeSWITCH were answered and echoed. The CPU load on the FreeSWITCH server approached 100 % at around 100 calls. Similar test with an Asterisk server would show 2-3 times less CPU load. Looping back to the Asterisk, thus avoiding a possible CPU-loading application (echo), did not show a significantly different result.
The test has been done on a CentOS 4 and a FC8 with similar result.
Any hints about how to increase the capacity to the level of several times the level of Asterisk – as reported by others? Are we possibly dealing with some hardware issues related to the NIC and its drivers. /Jon

[wasim at convergence.pk]

On Sun, Sep 28, 2008 at 9:50 PM, Jon Bruel <jbr@consiglia.dk (jbr@consiglia.dk)> wrote:

[jbr at consiglia.dk]

The protocol is SIP. The profiles relevant for the incoming call test with echo are here:
Dialplan:
*********
<!-- http://wiki.freeswitch.org/wiki/Dialplan_XML -->
<include>
<context name="public">
<extension name="From_Asterisk">
<condition field="destination_number" expression="^(K00003333100004444\d{3})$">
<action application="answer"/>
<action application="echo"/>
</condition>
</extension>
</context>
</include>

Sip Profiles:
*************
<!-- http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files -->
<profile name="external">
<!-- This profile is only for outbound registrations to providers -->
<gateways>
<X-PRE-PROCESS cmd="include" data="external/*.xml"/>
</gateways>

<aliases>
<alias name="outbound"/>
</aliases>

<domains>
<domain name="$${domain}" parse="true"/>
</domains>

<settings>
<param name="debug" value="1"/>
<param name="comfort-noise" value="false"/>
<param name="sip-trace" value="no"/>
<param name="rfc2833-pt" value="101"/>
<param name="sip-port" value="5080"/>
<param name="dialplan" value="XML"/>
<param name="context" value="public"/>
<param name="dtmf-duration" value="100"/>
<param name="codec-prefs" value="$${outbound_codec_prefs}"/> (comment: using PCMA)
<param name="hold-music" value="$${hold_music}"/>
<param name="use-rtp-timer" value="true"/>
<param name="rtp-timer-name" value="soft"/>
<param name="manage-presence" value="false"/>
<param name="aggressive-nat-detection" value="false"/>
<param name="inbound-codec-negotiation" value="generous"/>
<param name="nonce-ttl" value="60"/>
<param name="auth-calls" value="false"/>
<param name="rtp-timeout-sec" value="1800"/>
<param name="rtp-ip" value="$${local_ip_v4}"/>
<param name="sip-ip" value="$${local_ip_v4}"/>
<param name="ext-rtp-ip" value="$${local_ip_v4}"/>
<param name="ext-sip-ip" value="$${local_ip_v4}"/>
<param name="rtp-timeout-sec" value="300"/>
<param name="rtp-hold-timeout-sec" value="1800"/>
<!--<param name="enable-3pcc" value="true"/>-->
</settings>
</profile>

Gateway (one of them):
**********************
<include>
</gateway>
<gateway name="100004444300">
<param name="username" value="100004444300"/>
<param name="realm" value="10.3.1.21"/>
<param name="from-user" value="100004444300"/>
<param name="from-domain" value="10.3.1.21"/>
<param name="password" value="XXXXXX"/>
<param name="extension" value="K00003333100004444300"/>
<param name="proxy" value="10.3.1.21"/>
<param name="expire-seconds" value="600"/>
<param name="caller-id-in-from" value="false"/>
</gateway>
</include>

[brian at freeswitch.org]

Also need to know if you're 32bit or 64bit. That will make a huge
difference.

/b

On Sep 28, 2008, at 10:58 AM, Wasim Baig wrote:

[anthony.minessale at g...]

make sure the following ulimits are set in your shell before you start.

[jbr at consiglia.dk]

Regarding the 32bit vs. 64bit questions, I’m a bit uncertain about how I answer it, but here is some imformation, which you may use:
cpu family : 6
model : 15
model name : Intel(R) Pentium(R) Dual CPU E2140 @ 1.60GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm
uname –ar gives: Linux econel2.everdance.com 2.6.25.9-40.fc8 #1 SMP Fri Jun 27 16:25:53 EDT 2008 i686 i686 i386 GNU/Linux.

With respect to compiling the FS, I have not been aware of any options, so I just did the standard: bootstrap.sh, configure, make and make install.
I have tried to configure with some 64bit flags: CFLAGS="-m64 -fast" CXXFLAGS="-m64 -fast" LDFLAGS="-m64" ./configure --prefix=/opt/freeswitch --enable-core-odbc-support --enable-core-libedit-support --enable-64 --with-openssl=/usr/sfw, but I get an error:

checking for C compiler default output file name...
configure: error: C compiler cannot create executables

so I may need to install some 64bit libraries? If so some hints would be great! /Jon

[krice at suspicious.org]

What he means by 64bit is are you using a 64bit of fedora? If not grab the centos5 64bit iso and try that...
Also, several things upto and including hard disk access times can greatly affect the number of calls/sec and other things...

And yes freeswitch can greatly outperform asterisk by an order of magnitude... We routinely route 2000 concurrent calls


From: Jon Bruel <jbr@consiglia.dk>
Reply-To: <freeswitch-users@lists.freeswitch.org>
Date: Mon, 29 Sep 2008 09:31:54 +0200
To: <freeswitch-users@lists.freeswitch.org>
Subject: Re: [Freeswitch-users] Load test - performance not even matching Asterisk

Regarding the 32bit vs. 64bit questions, I’m a bit uncertain about how I answer it, but here is some imformation, which you may use:
cpu family : 6
model : 15
model name : Intel(R) Pentium(R) Dual CPU E2140 @ 1.60GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm
uname –ar gives: Linux econel2.everdance.com 2.6.25.9-40.fc8 #1 SMP Fri Jun 27 16:25:53 EDT 2008 i686 i686 i386 GNU/Linux.

With respect to compiling the FS, I have not been aware of any options, so I just did the standard: bootstrap.sh, configure, make and make install.
I have tried to configure with some 64bit flags: CFLAGS="-m64 -fast" CXXFLAGS="-m64 -fast" LDFLAGS="-m64" ./configure --prefix=/opt/freeswitch --enable-core-odbc-support --enable-core-libedit-support --enable-64 --with-openssl=/usr/sfw, but I get an error:

checking for C compiler default output file name...
configure: error: C compiler cannot create executables

so I may need to install some 64bit libraries? If so some hints would be great! /Jon

_______________________________________________
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

[jbr at consiglia.dk]

The load on the CPU was after the calls were set up, this indicated that’s not a disk access issue.

I’m running FC 8, i686, which I understand is 32 bit. Changing to FC 8 or 9 x86_64 is possible on the Intel® Core™2 Duo Processor, and if it’s worth it; I’ll do it. Does anyone have an idea of what the performance boost will be? /Jon

[mike at jerris.com]

No one can say what your performance will be, what I can say is the results you are getting are highly abnormal from what I have seen. Try it for yourself and see.


Mike

On Sep 29, 2008, at 5:26 AM, Jon Bruel wrote:

[shawnl at waterwheelne...]

Is it possible a group of us could all perform "the same exact" test and
compare specific results? I am a little concerned in that this may not
be "apples-apples".

for example running a specific script to generate the calls and
utilizing the same WAV playback, etc.

As I would be really interested in the results.

Shawn

Michael Jerris wrote:

[brian at freeswitch.org]

Install a 64bit version of your OS.


/b

Sent from my iPhone

On Sep 29, 2008, at 2:31 AM, "Jon Bruel" <jbr@consiglia.dk (jbr@consiglia.dk)> wrote:

[brian at freeswitch.org]

Yes core 2 is a 64bit CPU

Sent from my iPhone

On Sep 29, 2008, at 4:26 AM, "Jon Bruel" <jbr@consiglia.dk (jbr@consiglia.dk)> wrote:

[freeswitch at cartisso...]

And it IS worth it to switch to a x86_64 build on your system. Also,
make sure you run those ulimit statements as anthm had stated prior.
You current performance results seem very fishy.

--
Yossi Neiman
Cartis Solutions, Inc.
http://www.cartissolutions.com



Brian West wrote:

[jbr at consiglia.dk]

Thanks for the input.

I have now upgraded the OS to i86_64 (FC9), and I configured without libcurl, as recommended by Anthony. The FS loaded without problems apart from some “database is locked” errors, which may be harmless? I ran the ulimit as recommended to unlimit all resources. I started the FS after the ulimit. The same performance test showed a slightly better result. Without trying to make this too scientific, the improvement by going from 32 bit OS to 64 bit OS has been 10-20%, at the most. Still the performance is around 30-40% of the performance of Asterisk.

With 100 a-leg (no b-leg, as all calls are answered by the echo application) permanent channels the CPU idle is 10%, with 60% system-load and 30% CPU-load. So something is rotten in Denmark… /Jon

[anthony.minessale at g...]

What are you using to generate the load?
What are you using to deuce the load values?
You do realize that asterisk does not send RTP when you call it with sipp etc unless you have it configured to send some audio. Asterisk cannot generate it's own audio in most cases. So that 100 calls may not even be doing anything but sitting there blocking.
Also, if you are basing it on the load average, FS always has a high load average because it distributes the load on the threads to get max usage of the CPU thus the idle time and load average number can hover in the 100's eaisly when the box is still completely responsive.


Perhaps you should just let us into your machine and call you on the phone so we can get this over with for once and for all. We don't have time to keep going back and forth like this.

We are now 4/0 vs ppl saying there was a performance issue that boiled down to us ssh'ing to the box and finding them doing something wrong or misinterpreting the results so let's just get it over with.





On Mon, Sep 29, 2008 at 3:47 PM, Jon Bruel <jbr@consiglia.dk (jbr@consiglia.dk)> wrote: