Re: Performance in NIST

Francisco Javier Tellez Vaquero wrote:
Try profiling and revert back to this list. A few points:
1/ The performance results I posted were for dialog free operation. 
Dialog stateful operation introduces a significant overhead because of 
message ordering. You may notice messages being dropped.  Without 
dialogs, I have noticed an increase in performance of roughly 50%  but 
your milage may vary.
2. Invite transactions are held for a linger period. Again, if there are 
a huge number of such transactions and the tx table is being locked when 
removing them you will have lockout. Careful organization and splitting 
of the Transaction table may help here.
3. How long are your calls (i.e. the time between invite and bye?) 
Dialogs are held in memory for a while after BYE. This is to prevent 
issues with in-dialog requests that arrive late. When you remove an  
expired dialogs, the table is blocked and this can cause issues because 
each time you do a dialogid to dialog lookup you hold a lock on that 
entire table. If that table becomes huge, then the time it takes is 
significant. One might split that table and organize it using From tag 
into (i.e. have several tables) and do all kinds of other tricks to 
reduce locking. Wish I had the time to try such things. Take a hack at 
it and let us know how things improve. Also investigate if you can use 
concurrent hashmap for the Dialog table to get rid of that lock. Again, 
your effort will help optimize the stack.
4. Are ACKS getting dropped? Somebody recently reported a bug and a fix 
for lost ACKs in dialogs.  There was a race condition. This has been 
applied to the code on cvs (on the NIST repository). So try again.
5. Please help by profiling and posting details of where you think the 
bottle neck could be. I don't have the time for tuning this and my needs 
for high performance are not not that severe. If you want high 
performance, I can guide your attempts at optimizing the stack but I 
dont have the time to do so myself.

Regards

Ranga


> We need running with dialogs because we have to act as a B2BUA and we 
> have put gov.nist.javax.sip.REENTRANT_LISTENER = true.
>
> It's very strange the stack is not able to process more requests if 
> the CPU usage is not very high.
>
> I don't know if perhaps it can be a problem of synchronization or 
> something so.
>
> Regards,
> Fran.
>
>
>> From: "M. (Neo-Ranga) Ranganathan" <[email protected]>
>> To: "Francisco Javier Tellez Vaquero" <[email protected]>
>> Subject: Re: [nist-sip] Performance in NIST
>> Date: Fri, 26 May 2006 10:39:51 -0400
>>
>> Try running without dialogs (i.e. as a proxy server). Your thruput will
>> improve. Dialog imposes high overhead. Second, make sure you set
>> gov.nist.javax.sip.REENTRANT_LISTENER = true in your configuration
>> properties.
>>
>> On 5/26/06, Francisco Javier Tellez Vaquero <[email protected]>
>> wrote:
>>
>>>
>>> Hello,
>>> we have tried to make some tests to check performance. We're using a 
>>> Sun
>>> Solaris machine with 4 cpu's. The scenario is:
>>>
>>> SIPP                          NIST
>>> INVITE ------------------------->
>>> <----------------------------- 200
>>> ACK ----------------------------->
>>> BYE ----------------------------->
>>> <------------------------------200
>>>
>>> We see the stack processes less than 30 cps,
>>> but the CPU usage is not very high.
>>>
>>> We made another test, this time acting as a B2BUA:
>>>
>>> SIPP                          NIST                      SIPP
>>> INVITE ------------------------->
>>>                                  INVITE -------------------->
>>>                                   <-------------------------200
>>> <----------------------------- 200
>>> ACK ----------------------------->
>>>                                  ACK ------------------------>
>>> BYE ----------------------------->
>>>                                  BYE ------------------------->
>>>                                   <-------------------------200
>>> <------------------------------200
>>>
>>> This time the stack supports 40 cps (20 in each end) with also a not 
>>> very
>>> high CPU usage.
>>>
>>> It seems that perhaps there's something blocking (a bottle neck?) the
>>> input
>>> of the messages. We've tried to use several listening points and 
>>> different
>>> configurations.
>>>
>>> Regards,
>>> Fran.
>>>
>>>
>>>
>>> _______________________________________________
>>> nist-sip mailing list
>>> [email protected]
>>> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
>>>
>>
>>
>>
>> -- 
>> M. Ranganathan
>> "There are two ways to write error-free programs; only the third one 
>> works."
>> --  Alan Perlis
>
>
>
>


-- 
M. Ranganathan 

Advanced Networking Technologies Division,
National Institute of Standards and Technology (NIST),
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
tel:301 975 3664 , fax:301 590 0932 http://w3.antd.nist.gov/
Advanced Networking Technologies For the People!