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 _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev