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. _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
