[asterisk-dev] Help Solve the Mysterious Slowdown in Sip channel driver in Trunk!

[Steve Murphy]

Yet some more progress, for those that care:

On bug report 12772, er, http://bugs.digium.com/view.php?id=12772
I have attached the files:

profile.1.4.lowload.nocdr.txt 
profile.1.4.higherload.nocdr.txt 
profile.1.4compare.txt 


The 3 files are the result of backporting the work done in the
team/murf/mtxprof branch to 1.4; this work is in the 
team/murf/mtxprof4 branch. For the results gleaned for this 
message, these branches are compiled with MTX_PROF and DEBUG_THREADS
turned on (via make menuselect).

The first two files are the results of starting asterisk, making a
series of
sip calls, and then typing 'core show profile'. The first file is done
after a series of 2 non-overlapping sip-phone to sip-phone calls via
asterisk.

The second file is done after a series of over 800 calls made from sipp
to
asterisk, of .1 second duration, starting at a rate of 10 calls/sec, and
as
quickly as my fingers could type, ramping the calling rate up to 110
calls/sec.
The sequence was stopped as soon as about 800 calls were processed.


The third file is a comparison of 1.4 slow vs. fast, and a comparison
of 
1.4 vs trunk in 'higherload' mode.

The conclusions, copied from the end of the 3rd file, are:


        In the above, I draw the following conclusions:
        
        1. 1.6 locking and holding times are about, on the average, 
           roughly, twice the time of 1.4.
        2. channel_find_locked() is called 3 times in 1.4; it is 
           called almost 7000 times in trunk,
           and runs approx 6 times slower. 
           Here is a possible candidate.
        3. taskprocessor stuff gets called 21,000 times 
           in trunk, but wasn't used at all in 1.4
           -- something to look at.
        4. We have been "cheating" with trunk. All numbers 
           and hold times with the channel lock
           call removed from the handle_request_invite. 
           This roughly doubled the performance of
           chan_sip wrt call setup/teardown speed. It 
           just tends to lock up when you do
           a "stop gracefully"...

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/20080724/bcbe0361/attachment.bin