[asterisk-dev] [svn-commits] murf: branch murf/bug11210 r103686 - /team/murf/bug11210/doc/

[Russell Bryant]

Steve Murphy wrote:
> An excellent idea; I didn't see any obvious way to speed up anything
> with the registry, as there appeared not to be any searching going on
> within the registry.
> Just a renewal of scheduled events... I did give some effort to speeding
> up the sched code, but more can be done. 

Are there no peer lookups being done for a registration?  Certainly there are 
peer lookups when the registration is first processed, but there may not be when 
it gets refreshed ...

In chan_iax2, peers aren't cached anywhere, so there are peer lookups all over 
the place.  When I converted the module to astobj2 so that all of these lookups 
were hash table lookups, I was able to process something like 10 times the 
number of IAX2 registrations.  It was crazy ...

> So, I see only two alternatives to make chan_sip handle more: 
> 1. reduce the number of cpu cycles it takes to do its work
> 2. Allow the machine to do things in parallel (multithreading). Perhaps 
>    Josh's multithreading of chan_sip might help a LOT here,
>    as these distributions need not plug up the driver's ability 
>    to process requests...!

I think that you will find that as #1 is optimized more and more (and what you 
are working on is the top area for improvement), #2 will provide less benefit. 
I want to focus _hard_ on optimizing how chan_sip works now before we even 
thinking about multi-threading it.  Take a look at the commit history for 
chan_iax2 in the 1.4 tree to get a small idea of what a nightmare dealing with 
that has been.

While message processing takes time, it's not where Asterisk spends most of its 
time.  It's anything related to media handling that is the most performance 
sensitive.

> As to the testing, I'm totally all for it. In every testing scenario, as
> we push the driver to its limits, we can profile chan_sip to see where
> it is spending most of its cpu cycles, and see if any significant
> improvements can be made...

+1.  Again, I would rather see effort in this direction instead of thinking 
about making it multi-threaded.  :)

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.