VoIP Mailing List Archives

[regs at kinetix.gr]

In the process of trying to use Freeswitch in a production
environment I conducted a number of performance tests using
various servers. It was then that I noticed some strange behavior
from FS. When I stripped down the scenario I was using to a simple
bridge scenario, I stumbled upon a strange behavior.

The scenario as I stated is quite simple.

|---------| |---------|
| |------- Call from sipp------> | |
| sipp | | FS |
| | <------ Call back to sipp----| |
|---------| |---------|

I did not use an RTP stream for my calls just to test
the signaling alone.

The sipp scenario is the standard uac.xml scenario that
can be found integrated to sipp with the following options :

Test FS 1:

sipp <FS_IP>:5060 -s 55555555 -i <SIPP_IP> -mi <SIPP_IP> -ci <SIPP_IP>
-r 10 -d 5000 -l 100 -m 1000 -sf uac.xml

Calls : 1000
Successful calls : 1000
Idle CPU during tests : ~(35-60) % (35 during the generation of new
calls, 60 during the -l limit imposed by the test)

Note : 985 of them had a duration (billsec) of 10 and 15 of them had a
duration of 11.

I tried raising the call rate and limit...

Test FS 1:

sipp <FS_IP>:5060 -s 55555555 -i <SIPP_IP> -mi <SIPP_IP> -ci <SIPP_IP>
-r 20 -d 5000 -l 200 -m 1000 -sf uac.xml

Calls : 1000
Successful calls : 1000
Idle CPU during tests : ~0-30 % (0 during the generation of new calls,
30 during the -l limit imposed by the test)

THIS IS WHAT MAKES ME WONDER :

The distribution of the durations (billsec - not complete durations) :

183 calls with 10 secs billed duration
110 calls with 11 secs billed duration
238 calls with 12 secs billed duration
447 calls with 13 secs billed duration
22 calls with 14 secs billed duration

The sipp scenario is simple "hangup the phone after 10 secs". So, why am
I seeing these? Of course that has something to do with the stress the
machine
has been put through during the second test. But I can see it happening
to less stressful conditions (i.e. 15 calls per second) to a smaller extend.

I captured one of these calls and verified that when the sipp client
hangs up exactly 10 secs after the call start, FS receives the BYE
and replies with 200 OK. BUT it does not hang the second leg in a timely
manner i.e. it sends a BYE to the sipp server side 1-4 seconds
AFTER that. That explains the 11, 12, 13, 14 secs durations seen on the
second test. What is more interesting is that I would expect to see in
the CDRs the first and second leg to have different durations (since
the a leg BYE was received and aknowledged by FS in the correct time)
i.e. 10 and 14 secs accordingly. But what I get is the same duration for
both legs (14 secs).

This in my opinion is very dangerous on production environments (you get
charged by your provider more seconds that you charge your clients - or
- you falsely charge your clients with bigger durations although they
hunged up corectly (and you acknowledged it)).

NOTE No 1 : All the performance recommendations found in the wiki has
been applied. In fact only the essential modules that could make this
scenario work
were loaded.

NOTE No 2 : I tried using asterisk (as a point of reference - don't get
me wrong - I am not trying to start a flame war here). And it succeeded
doing on the same hardware 60 calls/sec with a channel limit of 400
sim. calls using only 50% of the cpu (maximum). No under any
circumstances I have seen the behavior above (this inability to hang
call legs in a timely manner). Even when I pushed asterisk to the limits
(80 calls per second 600 max call limit) and it started failing on some
calls it never failed to hangup the calls for both legs on exactly 10 secs.

NOTE No 3 : As you can tell I was using a very small machine for my
tests. When I moved the same tests to larger installations (Quad Core
Opterons and Xeons) I got proportional results to the above.

NOTE No 4 : The tests were performed in a LAN environment and since
there was no RTP involved I think there were no bandwidth issues there.

NOTE No 5 : The tests were performed using numerous SVN versions (latest
: 13610), the stable version and the 1.0.4pre8 version.

NOTE No 6 : Using the -hp switch made no noticeable change in behavior.

I am not trying to complain for FS's performance (far from it). I am
just somewhat disappointed seeing it performing in such a strange manner
when under stress. I would prefer a design that drops the calls after a
certain threshold than a design that incorrectly handles them all (I am
aware of the max sessions per second in switch.conf.cml - but I am
starting to see this behavior even with the cpu idling at about 80%). I
don't know if anyone else had the same experience when testing
Freeswitch. I can happily supply with all the test details (config
files, captures etc) to all interested parties.




--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: regs@kinetix.gr
-------------------------------------------


_______________________________________________
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

[brian at freeswitch.org]

On Jun 4, 2009, at 9:32 AM, Apostolos Pantsiopoulos wrote:

[msc at freeswitch.org]

[anthony.minessale at g...]

FS uses async rtp timers so you may want to set rtp-timer-name=none in the profile param to simulate asterisk conditions.
Also keep in mind that asterisk as an atvantage in a tiny crappy 32 bit single cpu box because that was what was popular when it was designed and the chance for race conditions is minimal because there is only 1 cpu. As you scale up to a 8 core 64 bit xeon you will set a drastic difference.

I will be happy to investigate this issue a bit if you'd like but i do not have any box like you describe so if I can't find anything
you may have to lend us your lab.


On Thu, Jun 4, 2009 at 12:47 PM, regs@kinetix.gr (regs@kinetix.gr) <regs@kinetix.gr (regs@kinetix.gr)> wrote: