[asterisk-dev] astobj2 and chan_sip; first results... wanna test drive it?

[Steve Murphy]

Hello!

I've been slaving over chan_sip for some time now, and have some
preliminary comparisons.

1. I'm comparing the 'stock' trunk version to team/murf/bug11210, where
I've:
       1. put all peers into an astobj2 hash table
       2. put all users into an astobj2 hash table
       3. put all dialogs (sip_pvt) into an astobj2 hash table
       4. put all peers with an IP into an astobj2 hash table.
       5. added a small hashtab to the ast_sched struct, 
       6. changed the ast_sched schedq linked list to be a doubly-linked
list

2. In my first round of performance comparisons, I'm running asterisk
   compiled with no optimizations, and the -pg option added to profile
   the code. So, don't expect asterisk to run miraculously fast.

3. Also, the test machine (ala digium) is NOT a powerful machine... 
   with 1 gig of memory and running an old version of Ubuntu. It's a
Dell 
   32-bit PC, 2.8Ghz, P4. So, don't expect asterisk to run miraculously
fast.
   At least compared to the quad-processor 64-bit monsters that folks
like to
   brag about! Oh, btw, I never noted any swapping throughout my
testing.

4. All testing done with 'ulimit -n 8196' done previously. I have to do
this,
   or I bump into the 'too many open files' problem. The threshold is
about 195
   simultaneous calls.

5. I'm using the latest version of sipp to thrash asterisk. I have two
basic
   test scenarios: Run a LOT of really really really short calls, versus
running
   a lot of LONG calls, and see how many you can run at once before
problems set
   in...

   for the short calls: 
     ./sipp -sn uac 192.168.134.252 -s 12 -d 100 -l 256
   (don't worry, you'll never get close to 256 sim. calls! [at least,
not
    on MY machine!!!]  sipp will start out at 10 calls/sec; keep bumping
up
    the call limit until you start seeing retrans and timeouts.
Things'll just
    plain go nuts. When you hit this, you've gone too far.)

   for the long calls:
    ./sipp -sn uac 192.168.134.252 -s 12 -d 100000 -l 270
   (run this several times, and vary that last number to find a limit
that
    will allow you to run stably. If sipp goes nuts and cpu idle drops
to 0%,
    stop the test and try again with a lower number!)

6. On my asterisk machine, the sipp entry in sip.conf looks like this:
     [asterisk02]
     type=friend
     context=sipptest
     host=192.168.134.240
     user=sipp
     canreinvite=no
     disallow=all
     allow=ulaw

7. and the sipptest context in extensions.conf looks like this:

      context sipptest
      {
        _X. => {
                Answer();
                Background(demo-instruct);
                Background(demo-instruct);
                Background(demo-instruct);
                Background(demo-instruct);
                Hangup();
               }
     }
  (I looked around for the longest playing soundfile I could find.
Still, playing
   it 4 times may not take the full 100 secs. Tough. Close enough.)

8. To add spice to life, after the [asterisk02] entry in sip.conf, I
added over
   4600 other friend entries. 

9. Asterisk is running on 192.168.134.252; sipp runs on 192.168.134.240.
   Between them are 2 cheap 8-port switches and a router/switch.
Everything is
   running at 100mbit, and the kids are probably killing each other
using 
   network intensive gaming maneuvers in the same network.

OK, I admit it, I feel like a kid who's just put a turbocharger on his
450 V-8. Let's see what this baby can do on the open road. I have the
advantage of not having to worry about what the police/sheriff/FBI will
think!

Results:

On trunk:

Short Call test:  at 100 calls/sec, I start seeing some retransmits
after a while
                  at 120 calls/sec, I see 0% cpu idle and sipp goes
nuts.

Long Call test: at 270 simultaneous calls, cpu idle bobbles down to 0%
                       frequently, but asterisk seems to hang on.
                at 280, things fall apart pretty swiftly.

On my turbocharged V8 version in team/murf/bug11210:


Short Call test: things fall apart at 450 calls/sec. cpu idle drops to
0% and 
                      asterisk falls apart.


Long Call test:  at 300 simultaneous calls, cpu hits 0% every now and
then, but
                        asterisk remains stable.
                 at 310 simul. calls, we are stable for quite a while,
but the
                        cpu idle % times keeps bobbing up and down, and
when it
                        hits 0% hard, asterisk starts to trip up.

Conclusions: while I can get 4x performance for short calls, I seems to
be dealing with some sort of network limit or something for long calls.
Still, using hash tables to cut cpu usage, asterisk seems to be able to
squeeze a few more calls in before it gets overloaded (about 10% or
so?).

Caveats: There's still a few issues to clear up, namely 'pedantic'
dialog lookups need to be addressed, and there's an occasional timing
issue between the rtp stuff, and dialog destruction. It happens about as
often as asterisk crashes
in trunk from a bad peer pointer, btw, both problems occur during module
reload/unload... always work to do!)

So, anyone wanna take this puppy out for a drive?

murf


                       


-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20080103/5f9e0707/attachment.bin