[asterisk-users] Improving the speed of chan_sip

[Steve Murphy]

Hello--

Why do I target chan_sip for so much effort?  Because, 
it seems to me, chan_sip is probably the most used channel 
driver in the asterisk community!! (and, of course,
the zap/dahdi driver, is also pretty popular)

I haven't had time to follow up on chan_sip, and I probably 
won't for several months. 

But, if I had time, here is what I'd do:

There are two ways to speed up chan_sip, and they are separate issues,
tied together on how many cpu cycles they use up:

1. Call setup/teardown (invites/hangups) -- limits the calls/sec
asterisk can handle.

2. Sound processing: Moving around the sound data (frames) between
channels,
-- limits the number of simultaneous conversations asterisk can handle.

For Call setup/teardown speed improvements:

a. I would profile how much time is spent by the handlers in the 
   various situations (handling invites, etc).
   Theory: the cps (calls/sec) rate is currently limited by 
           the time it takes to process INVITE requests. You
           measure the time spent in handling INVITEs and
           find the average number of microseconds spent,
           and my suspicion is that the inverse of this
           time (in sec) would be the number of calls/sec
           chan_sip can handle. If this is the case, then
           find where the invite is spending all its time.
           Theory: The majority of chan_sip's INVITE
                   processing time is spent in creating the
                   thread for running the PBX.

     If both theories above prove true, then to increase the
     cps rating of asterisk, you institute a fairly large
     thread pool (like what chan_iax does). Chan_iax uses
     its thread pool to handle network request processing;
     chan_sip can do this also, or just use its thread pool
     for pbx threads. Going the pbx_start route might
     be tactically better-- it could be used to speed
     up EVERY channel driver, instead of just chan_sip.
     Either way, thread pools would reduce the invite
     time substantially, and allow a higher cps rating.

     Also, if the above theories both prove true, then
     I'd copy the thread pool stuff in chan_iax,
     and make it pretty generic, and use
     it as a basis for forming a thread pool for
     running the pbx, then retrofit the chan_iax
     code to also use the generic pool for 
     network request handling...

     If either or both of the above theories prove 
     false, then the only path left is profile 
     asterisk running near saturation, and optimize
     the routines that are hogging the most cpu
     cycles.

To Enhance the Number of Simultaneous Conversations:

b. Carefully profile asterisk while near saturation,
   find the chief cpu cycle absorbers, and optimize them.
   Theory: Optimizing maybe the top 5 cycle-burning routines
   could yield a noticeable improvement in how many
   simultaneous conversations asterisk could handle.
   Of course, for just numbers, you use the fastest
   codecs. If the codecs end up being the limiting
   factor, (and they may just be), optimizing those
   might be very rewarding, also, but then again,
   they are pretty optimized already (I hope!).

   When it comes to optimization, there are often
   surprising cases where improvements can be made!

If some brave soul is interested in helping with this,
feel free to dive in.

murf

-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20080807/5aff50d7/attachment.bin