[asterisk-users] Improving the speed of chan_sip

[Pavel Jezek]

Steve Murphy wrote:
> 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.
>   

one of the big issues in sip callsetup performance, that appears to me 
in current trunk, is about 500ms delay in propagation SIP/OK message 
between bridged parties
eg.: one party answers call, send SIP/OK with SDP to asterisk, asterisk 
then forwards it to other party, but with unacceptable delay about 500ms!
this is so much, that users complaining about lost first word of speech 
communication,
I posted info about this to bugreport, that seems to be related to this, 
look at my message:
http://bugs.digium.com/view.php?id=12708#91173
I also attach graph picture from wireshark, that clearly ilustrated, 
where is problem.... (OK-SDP-delay.png )
PJ






> 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
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> AstriCon 2008 - September 22 - 25 Phoenix, Arizona
> Register Now: http://www.astricon.net
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users