[164626] in North American Network Operators' Group
Re: Homegrown SIP load testing platform
daemon@ATHENA.MIT.EDU (Joshua Goldbard)
Thu Jul 25 11:35:20 2013
From: Joshua Goldbard <j@2600hz.com>
To: Jon Chleboun <jon.chleboun@gmail.com>
Date: Thu, 25 Jul 2013 15:34:44 +0000
In-Reply-To: <CADW8q=YVv19Ft9fbSm0t5Ws7V8p2Dy1jaWf8U2-rs5ZQXrs9Lw@mail.gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hey Jon,
This comes up on the voice ops list pretty regularly. Some folks have menti=
oned SIPVicious as a method for sip testing, but I think that's more for pe=
ntesting.
The Empirix stuff seems to be the state of the art today. On a previous thr=
ead I talked a bit about quality monitoring and why the stuff in the indust=
ry today isn't really giving you the kinds of feedback you're looking for, =
but load testing is a different problem.
If you do end up playing with the interrupt timers on the NICs, and you're =
successful, I'd love to hear what worked.
Some food for thought: we've got a set of tickets open with the TAC because=
a large router (sorry I don't have the model number) bricked in a repeatab=
le fashion at 300 calls per second. It shouldn't be true, but sometimes the=
gateway device is the limitation, although I don't know if this is applica=
ble in your example.
Anyways, I'm sorry I can't be of more help, but I personally see load testi=
ng at scale as a big unsolved problem for operators.
Cheers,
Joshua=20
Sent from my iPad
On Jul 25, 2013, at 7:32 AM, "Jon Chleboun" <jon.chleboun@gmail.com> wrote:
> I am interested to see if y'all have recommendations for putting together=
a
> SIP load testing platform using general purpose hardware and open-source
> (or inexpensive) software. We are aware of Empirix Hammer and similar
> solutions, and we are looking to see if there is an alternative option.
>=20
> Goals:
> - Generate somewhere on the order of 20k phone calls with real SIP and RT=
P.
> - Route the flows through our VoIP infrastructure to test performance
> limits.
> - Receive and analyze the SIP and RTP on the other end to find out at wha=
t
> load the signaling and/or media start to break down.
>=20
> Attempted already:
> - SIPp spread across many servers. Here the limiting factor seemed to be
> the CPU load from the interrupts from each packet. The CPU on the server=
s
> sending and receiving the phone calls got bogged down before the VoIP cor=
e.
> - We have dabbled with interrupt moderation in the NIC drivers, but this
> has not seemed to help very much.
>=20
> Looks interesting:
> - Has anyone had success using PF_RING with Direct NIC Access and libzero
> from the folks at ntop? Has anyone been able to use this with SIPp or som=
e
> other SIP and RTP generator?
>=20
>=20
> Many thanks,
>=20
> Jon Chleboun
