On Fri, 2008-02-15 at 08:42 +0100, Johansson Olle E wrote: > 14 feb 2008 kl. 21.25 skrev SVN commits to the Digium repositories: > > > Author: murf > > Date: Thu Feb 14 14:25:11 2008 > > New Revision: 103686 > > > > URL: http://svn.digium.com/view/asterisk?view=rev&rev=103686 > > Log: > > Adding some documentation for testing sip channel performance using > > sipp. > > Murf! > Thank you! > > Maybe we can start creating a collection of SIPP tests to run various > scenarious. > I would like to test how registrations and subscriptions affect the > stack too. > > Imagine your PVT list with 500 subscriptions, 50 per extension. Then > place > 200 calls and you will see asterisk having a lot of fun delivering > call states > to 50 subscribers per extension. That would be a good stress test for > your branch, > since it not only involves INVITE/BYE but also traversing the list for > SUBSCRIBEs > and having a much larger list of PVT's than just the calls. > > /O
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. As to distribution, there are few shortcuts there, also... If you must keep a large number of subscribers happy, you are going to be shipping out a lot of data. However, 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. Since the failure mode of Asterisk under heavy load is that it ends up having more to do than the CPU can handle. Timeouts start to occur as it tries unsuccessfully to keep up, and the retransmits add to the burden in a cascading spiral into death. 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...! 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... murf -- Steve Murphy Software Developer Digium
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ --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
