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

[Steve Murphy]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20080215/c136a179/attachment.bin