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

[Johansson Olle E]

26 nov 2006 kl. 22.14 skrev Ryan Mitchell:

> Hi,
>
> I have one system with ~ 3400 peers registered on the box (Asterisk
> 1.2.10),

With or without realtime?

> 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.
>
Please check the bug tracker if you find a similar situation reported.

> 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);

Sounds like an idea.

For registrations and subscriptions, we do have open bug reports.
My idea is to set a maximum limit on number of register/subscribe  
requests
we handle at a given time and send the rest an error message with a
retry-after header to ask them to come back later.
Does that sound like a plan?

For realtime, my thought is that it would lower the load on the db  
subsystem as well as
the transaction handling in chan_sip.

/O