Load Testing (was Re: [asterisk-dev] Rate limiting traffic to address potential DoS issues?)

[Greg Boehnlein]

On Wed, 27 Sep 2006, Jeremy McNamara wrote:

> Jared Smith wrote:
> > I know I talked to several people about this at VON -- does anybody have 
> > a lead on some good high-end VoIP call generators we can use to test 
> > Asterisk and make it better?
> 
> At various points this last year, I have had access to a Spirent Abacus, 
> but nobody could tell me how they wanted me to profile Asterisk.   I 
> provided oprofile data to various people, but I never received any 
> feedback other than 'try to use gprof' and see what it says. However, in 
> the limited time I had, I couldn't figure out exactly what gprof was 
> needing to get any sort of data out of it.
> 
> I can request access to another Abacus for Astricon, if a few of us 
> dedicate to make a serious effort to get some good data this time.

That would be great. However, we have been using SIPP for stress testing 
of various SIP platforms and have found it to be very flexible. It 
supports the creation of XML "Scenarios" that can imitate pretty much any 
SIP transaction you would like.

It also supports an RTP reflector, such that it will echo back any RTP 
that it receives to emulate media payload. Took me a while of testing with 
it and it not working before I realized that Asterisk's RTP stack is 
synchronous and requires an inbound RTP packet before it will kick off an 
outbound packet, but once I injected a g729 payload packet, everything 
started working.

It was my suggestion that the developer community collaborate on a 
standardized framework of SIP transaction tests and that Digium require 
all releases of Asterisk to be regression tested through it. This could 
include DTMF testing, various media and codec payloads etc.. This is 
similar to the testing process that SipX goes through, and they catch an 
awful lot of gotchas.

Imagine the benefit of having a standardized, rigorous set of tests to run 
the SIP stack through between releases? If you could collect the data and 
track it in a central repository, you might actually be able to see 
granular performance improvements between releases that way. Just seems 
like good software engineering and QA control to me.

-- 
    Vice President of N2Net, a New Age Consulting Service, Inc. Company
         http://www.n2net.net Where everything clicks into place!
                             KP-216-121-ST