[asterisk-dev] chan_sip - performance, and OPTIONS poking for 1000s of peers

[Ryan Mitchell]

Hi,

I have one system with ~ 3400 peers registered on the box (Asterisk
1.2.10), about 1/2 of which are online at any given time. By far the
biggest fraction of work for the SIP stack is in processing REGISTER,
NOTIFY, and OPTIONS requests (incoming and outgoing), and not in call
processing itself, let alone transcoding or anything else Asterisk is
doing. The sip stack frequently suffers from thread lockups under high
loads -- usually a hard deadlock of some kind where absolutely no sip
packets will be emitted.

Anyway, analyzing traffic patterns with Ethereal, I see fairly uneven
packet densities in terms of packets per second. One moment I could see
> 200 sip packets/sec, then next moment < 50. The biggest culprits are
OPTIONS requests, the responses, and the various packets that clients
send to ping the server and keep their firewall pinholes open.

So I looked at the few different places in chan_sip.c that determine
when OPTIONS requests are scheduled and altered the code to add/subtract
some randomness to the timeout. Something like this:

int to2 = DEFAULT_FREQ_OK + thread_safe_rand() % 8000 - 40000;
peer->pokeexpire = ast_sched_add(sched, to2, sip_poke_peer_s, peer);


Over time this causes the OPTIONS pokes to spread out more evenly. Net
result is that the peak packets/sec Asterisk has to process is much
lower, even though the average is the same.

Does this sound like a good or a bad idea? It's a relatively simple,
change; if this is useful I'll contribute a patch.

Sorry about the long post. If anyone has any other good tips for tuning
chan_sip.c that hasn't already been covered in the forum please chime
in. I'm eagerly awaiting 1.4, and may switch to using beta if my testing
finds it's stable enough for this app.

--Ryan