NIST-SIP Performance improvements -- self test results.

Hello!

Well OK. performance is a relative term.  I did a small performance 
experiment for a dialog stateful UAS to UAC application  on a single 
machine.

Here are my results obtained on my laptop which is a 1.8 Ghz 1 gigabyte 
single processor intel machine. The call flow is very simple - UAC 
initiates 300 concurrent dialogs by sending out 300 invites and UAS 
Tears down eaach dialog right after ACK.
   

First, I did these experiments with an infinite thread pool size. I 
created  300 simultaneous dialogs. Here are the results I got:
 
no time between requests -- 11 caps  (clearly the stack is choking and 
dropping requests here)
10 milisec  between INVITE requests ... 15 caps
 20 milisec between                          .... 18 caps  (seems like 
the optimum operating point).
 30 milisec between                           ... 18 caps.
50 milise   between                           .... 17 caps.

Next I set the thread pool size to the number of processors on my trusty 
machine  ( which is exactly one) AND upped the number of concurrent 
dialogs to 500 ( tut tut... bad experiment design to change two variable 
simultaneously but what the heck) and then I got these results

0 milis between requests  21 caps
10 milis between requests 55 caps
20 milis between requests 41 caps
30 milis  between requests 29 caps

Total utilizaton of my processor between the two JVM's was a pretty 
decent 70% or so.  Presumably the rest is blocking due to message passing.

So the moral of the story is :

1. you *can* achieve decent call thruput for dialog stateful peer to 
peer operation on local host on a SINGLE processor machine ( with the 
latest tweaks I put in place which seems to really work well).  BUT.. of 
course YMMV.
2. You should set gov.nist.javax.sip.THREADPOOL_SIZE = # of processors 
on your machine.
3. You should rate limit your incoming Requests/Responses to about 1 
each 10 miliseconds else you will wind up dropping requests.  (will try 
to throw in a stack config param that allows you to rate limit your 
incoming reuqests for a provider).


I'll post similar results for proxy operation when I can find some time 
to work on it.


I've provided the code so that you can experiment and tell us how things 
look on your super duper multiprocessor hardware :-) The application may 
be found in src/test/load/concurrency


Now I am not sure why anybody would want to procecss requests at this 
rate on a User Agent but that is an entirely different question. As far 
as I am concerned, thats enough tweaking for the moment.

Hope this helps.

Regards,

Ranga.

-- 
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!