[Asterisk-Users] SIP calls-per-second performance test tool

[John Todd]

At 11:39 AM -0700 on 5/12/04, Chris A. Icide wrote:
>
>
>On 01:16 PM 5/10/2004, John Todd wrote:
>>
>>http://sipp.sourceforge.net/
>>
>>Anyone care to throw this at Asterisk to see what happens?   I would,
>>but I am having significant temporal shortfalls recently due to the
>>apparent warping of the space/time continuum when I answer the phone
>>with clients/associates.  It seems that entire days pass by before I
>>hang up... very odd, and very counter-productive to getting good
>>Asterisk work done.
>>
>  >JT
>JT,
>
>I ran this against my home office asterisk box (4 analog lines, 
>about 20 sip UA's, 2.6G P4, 512MB system).  I just ran the basic 
>test, routing the request to Playback(invalid) then Hangup.
>
>During the test I had two UA's (a cisco 7960 and an analog phone 
>connected to an ATA 186) dialed into MoH.
>
>Asterisk was running in background with no options to the command 
>line, and one remote CLI connection.
>
>The system was able to handle 20 calls per second without any call 
>failures.  Beyond 20 calls per second I began to see call failure. 
>The quality of the two MoH calls was perfect the entire time.
>
>I then proceeded to crank up the call volume and right about 200 
>calls per second, all call attempts became failures, and no new 
>calls succeeded).  At this point I got some interesting errors on 
>the CLI related to maximum file descriptors (which I didn't worry 
>too much about at the time), however, when I cranked the call volume 
>back down to under 20 cps, all calls still failed.  I had to shut 
>down asterisk and restart to restore the system.  However on an 
>interesting note, at no time during any of the tests did the MoH 
>calls lose quality or suffer any artifacts.
>
>Interesting program, and I'll set up a much more scientific test 
>system and post some results on multiple systems (1G Pentium, 2.6G 
>Pentium, and a Dual AMD system on 2.4 and 2.6 kernels) sometime soon.
>
>-Chris


Chris -
   It does not appear that sipp is a User Agent that is authenticated, 
which is probably something that needs to be included in the tests, 
since that adds ~30% additional packet chatter on an INVITE, and 
involves some computation which could significantly change the 
results of what SIPP finds vs. "real-world" situations.

   More investigation would lead me back to sipsak 
(http://sipsak.berlios.de/) to see if perhaps some grafting of the 
two packages could be made, such that the extended features of sipsak 
(including authorization) could be programmed to include the RTP echo 
module and "end-to-end" mode that sipp appears to support.  I'm not 
sure which program would be better to modify...

JT