PJSIP - High Performance Open Source SIP Stack
Last Update: $Date: 2007-01-08 02:05:48 +0000 (Mon, 08 Jan 2007) $
|
|
|
PJSIP is designed from day one to have very high performance, as well as to
have very small footprint. Some of the performance data will be given in this page.
[Date: July 11th, 2006, PJSIP v0.5.6.5]
This article shows various performance numbers of PJSIP, such as stateless
performance, transaction performance, and call performance. It shows very good
result, with more than 7,000 transactions can be processed per second on a single processor
P4/2.66GHz machine, as the figure below shows:
Please read the full article for more information about the performance, as
well as how the benchmark was performed.
[Date: July 19th, 2006, PJSIP v0.5.7]
Looking for a very fast SIP parser (and open source)? Then look no further, as
this benchmark report shows that PJSIP can parse more than 70 thousands
of typical SIP messages per second.
Please read the report to see other performance statistics as well.
Note: The report was generated by test-pjsip project (in pjsip/build directory), and PJSIP was compiled with full optimization as
in the Full Benchmark Report article
above. See the file msg_test.c for the messages that were used in the parsing benchmark.
SIP Stack Scalability
[Date: Sept 19th, 2006, PJSIP v0.5.7.8]
The PJSIP Full Benchmark Report above
shows that the optimal number of worker threads is equal to the number of
processors in the system. However, the tests in that article were done
in single processor system, so it was still questionable if the same
principle still holds when the tests are performed on multi-processor
systems.
So here we perform some little tests to see the performance scalability
of the SIP stack on multi-processor system. For this test, we used
a single machine with the following specifications:
- Compaq server with quad Xeon processors (4x500Mhz CPU), 2GB RAM installed.
- RedHat Fedora Core 5 with Linux 2.6.15-smp kernel.
The sample program pjsip-perf was used to make outgoing and receive
incoming calls. Only one instance of pjsip-perf was used in the test,
and only TCP was tested (it was suspected that UDP introduces packet drops
even when the tests are done in a single program).
Spesificly, the following command was used to perform the test:
|
$ ./pjsip-perf --method INVITE --use-tcp --thread-count N 'sip:2@127.0.0.1;transport=tcp'
|
where N is the number of threads to be tested.
The result of the test is shown in the chart below:
From the above results, I believe we can conclude that:
- The SIP stack is scalable
Performance increases significantly when multiple processors are
used and multiple threads are configured. The performance increases when more threads
are added, until the maximum performance is achieved when number of threads are equal
to number of processors installed in the system.
- The SIP stack is efficient
Using more threads than the number of installed processors will not increase
the performance. This shows that the SIP stack is very efficient in utilizing the CPU
(e.g. there is no unnecessary blocking anywhere) so that adding more threads than
the available CPU will not have any benefits as it only adds overhead to the processing.
- Scalability is non-linear (unfortunately)
Doubling the number of
processors/threads from one to two increases the performance by 80% (1064 cps compared
to 592), while doubling the number of processors from two to four only increases the
performance by 35% (1443 cps compared to 1064).
This was caused by contentions introduced by objects which have to be shared by
all threads (for example the transaction hash table, transports, dialog table, etc.).
Although care has been taken to reduce these contentions and to promote parallelism as
much as possible (by reducing the duration a thread owns exclusive lock to these global
objects), unfortunately we can not remove this effect altogether.
|
|
