[asterisk-dev] chan_sip -- improving the speed of sip reloads

[Steve Murphy]

On Tue, 2007-11-20 at 22:31 -0600, Russell Bryant wrote:
> Steve Murphy wrote:
> > This is an interesting thought. I shall look into that. But, the code in
> > IAX2 uses the iterators, also... so, if it is a big win to move over, I
> > may rewrite those loops, also, then.
> 
> My feeling is that there are situations where the iterator is preferred over the
> ao2_callback() method of executing code for every object in the container.
> Specifically, if the code inside the traversal could be somewhat computationally
> expensive, then you may want to avoid holding the container lock for the entire
> traversal.
> 
> For example, the code to handle the "iax2 show peers" CLI command uses an
> iterator so that it doesn't block the container for the entire duration of
> writing all of the peer data to the CLI fd.  Instead, the container lock is only
> held for very short periods of time.  The reason is that any sort of delay in
> the writes blocks every single IAX processing thread from doing any other
> lookups in the container, which have a much higher priority than the response at
> the CLI.
> 
> Of course, you increase the overall runtime of the iteration due to having to
> contend for the lock so many times.  But, hopefully the benefits in response
> time by other processing threads make it worth it.  I guess we'd have to do some
> profiling to really know for sure.  But, I remember that there were noticeable
> effects when I was doing some test calls through a system, loading it with a ton
> of IAX2 registrations, and executing various CLI commands.


In the IAX2 implementation, really, there were only 2 places where the
code iterates that concerned me, and that is in iax2_getpeername(), and
iax2_getpeertrunk(). If these functions are (or could be) called
frequently, a good alternative is to create another hashtable keyed by
the ip/port info so these things can just be directly looked up instead
of a linear search. I would think this whether iterators had a problem
or not. If they are frequently called, I would go the hashtable route
before I would change to a different method of iteration.

The other places, mostly cli type reports, are not so frequently run,
and really have no efficiency issues in that respect. As long as they
work, and don't create problems, that is. Sounds like they are optimum
as-is.

murf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3239 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20071121/b125776b/attachment.bin