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.


PJSIP Full Benchmark Report

[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:

abstraction cost

Please read the full article for more information about the performance, as well as how the benchmark was performed.


SIP Parser Benchmark

[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@;transport=tcp'
where N is the number of threads to be tested.

The result of the test is shown in the chart below:

SIP scalability chart

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.