-
Notifications
You must be signed in to change notification settings - Fork 0
/
high-performance-sip.htm
118 lines (114 loc) · 6.21 KB
/
high-performance-sip.htm
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>PJSIP Benchmark - High Performance Open Source SIP Stack</title>
<link rel="stylesheet" type="text/css" href="/style/style.css">
</head>
<body>
<!--#include file="header.html" -->
<TABLE id="ContentSubTable" cellSpacing="6" cellPadding="4" width="100%" border="0">
<TR>
<TD>
<H1>PJSIP - High Performance Open Source SIP Stack</H1>
<p>Last Update: $Date: 2007-01-08 02:05:48 +0000 (Mon, 08 Jan 2007) $</p>
<HR>
</TD>
<TD width="15%"></TD>
</TR>
<TR>
<TD>
<P> </P>
<P>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.</P>
<P> </P>
<H2><A href="/testing/0.5.6.5/bench.htm">PJSIP Full Benchmark Report</A></H2>
<BLOCKQUOTE dir="ltr" style="MARGIN-RIGHT: 0px">
<P>[Date: July 11th, 2006, PJSIP v0.5.6.5]</P>
<P>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:</P>
<P align="center"><IMG src="testing/0.5.6.5/abstraction-costs.jpg" ALT="abstraction cost"></P>
<P>Please read the full article for more information about the performance, as
well as how the benchmark was performed.</P>
<P> </P>
</BLOCKQUOTE>
<H2><A href="/testing/0.5.7/pjsip-static-bench-win32-msvc.htm">SIP Parser Benchmark</A></H2>
<BLOCKQUOTE dir="ltr" style="MARGIN-RIGHT: 0px">
<P>
[Date: July 19th, 2006, PJSIP v0.5.7]</P>
<P>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 <STRONG>70 thousands
of </STRONG><A><STRONG>typical</STRONG></A><STRONG> SIP messages per second</STRONG>.
Please read the report to see other performance statistics as well.</P>
<P>Note: The report was generated by test-pjsip project (in <A href="/cgi-bin/viewcvs.cgi/pjproject/trunk/pjsip/build/">pjsip/build</A> directory), and PJSIP was compiled with full optimization as
in the <A href="/testing/0.5.6.5/bench.htm">Full Benchmark Report</A> article
above. See the file <A href="/cgi-bin/viewcvs.cgi/pjproject/trunk/pjsip/src/test-pjsip/msg_test.c?view=markup">msg_test.c</A> for the messages that were used in the parsing benchmark.</P>
</BLOCKQUOTE>
<P> </P>
<A NAME="scalable"></A><H2>SIP Stack Scalability</H2>
<BLOCKQUOTE dir="ltr" style="MARGIN-RIGHT: 0px">
<P>[Date: Sept 19th, 2006, PJSIP v0.5.7.8]</P>
<p>The <A href="/testing/0.5.6.5/bench.htm">PJSIP Full Benchmark Report</A> 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.</p>
<p>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:</p>
<UL>
<LI>Compaq server with quad Xeon processors (4x500Mhz CPU), 2GB RAM installed.</LI>
<LI>RedHat Fedora Core 5 with Linux 2.6.15-smp kernel.</LI>
</UL>
<p>The sample program <b>pjsip-perf</b> was used to make outgoing and receive
incoming calls. Only one instance of <b>pjsip-perf</b> 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).</p>
<p>Spesificly, the following command was used to perform the test:</p>
<TABLE class="fixedtable" cellSpacing="2" cellPadding="4" width="100%" border="0">
<TR>
<TD bgColor="beige">
$ ./pjsip-perf --method INVITE --use-tcp --thread-count N 'sip:2@127.0.0.1;transport=tcp'
</TD>
</TR>
</TABLE>
where N is the number of threads to be tested.
<p>The result of the test is shown in the chart below:</p>
<CENTER>
<IMG src="/testing/0.5.7.8/sip_scale.jpg" alt="SIP scalability chart">
</CENTER>
<p>From the above results, I believe we can conclude that:</p>
<DL>
<DT><B>The SIP stack is scalable</B>
<DD><p>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.</p>
<DT><b>The SIP stack is efficient</b>
<DD><p>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.</p>
<DT><b>Scalability is non-linear (unfortunately)</b>
<DD><p>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).</p>
<p>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.</p>
</DL>
</BLOCKQUOTE>
<P> </P>
<P> </P>
</TD>
<TD></TD>
</TR>
</TABLE>
<!--#include file="footer.html" -->
</body>
</html>