Merged revisions 243258 via svnmerge from
[asterisk/asterisk.git] / doc / chan_sip-perf-testing.txt
1 Measuring the SIP channel driver's Performance
2 ==============================================
3
4 This file documents the methods I used to measure
5 the performance of the SIP channel driver, in 
6 terms of maximum simultaneous calls and how quickly
7 it could handle incoming calls.
8
9 Knowing these limitations can be valuable to those
10 implementing PBX's in 'large' environments. Will your
11 installation handle expected call volume?
12
13 Quoting these numbers can be totally useless for other
14 installations. Minor changes like the amount of RAM
15 in a system, the speed of the ethernet, the amount of
16 cache in the CPU, the CPU clock speed, whether or not
17 you log CDR's, etc. can affect the numbers greatly.
18
19 In my set up, I had a dedicated test machine running Asterisk,
20 and another machine which ran sipp, connected together with
21 ethernet.
22
23 The version of sipp that I used was sipp-2.0.1; however, 
24 I have reason to believe that other versions would work 
25 just as well.
26
27 On the asterisk machine, I included the following in my
28 extensions.ael file:
29
30 context test11
31 {
32         s => {
33                 Answer();
34                 while (1) {
35                         Background(demo-instruct);
36                 }
37                 Hangup();
38         }
39         _X. => {
40                 Answer();
41                 while (1) {
42                         Background(demo-instruct);
43                 }
44                 Hangup();
45         }
46 }
47
48 Basically, incoming SIP calls are answered, and
49 the demo-instruct sound file is played endlessly
50 to the caller. This test depends on the calling
51 party to hang up, thus allowing sipp to determine
52 the length of a call.
53
54 The sip.conf file has this entry:
55
56 [asterisk02]
57 type=friend
58 context=test11
59 host=192.168.134.240 ;; the address of the host you will be running sipp on
60 user=sipp
61 directmedia=no
62 disallow=all
63 allow=ulaw
64
65 Note that it's pretty simplistic; no authentication beyond the host ip, 
66 and it uses ulaw, which is pretty efficient, low-cpu-intensive codec.
67
68
69 To measure the impact of incoming call traffic on the Asterisk
70 machine, I run vmstat. It gives me an idea of the cpu usage by 
71 Asterisk. The most common failure mode of Asterisk at high call volumes,
72 is that the CPU reaches 100% utilization, and then cannot keep up with
73 the workload, resulting in timeouts and other failures, which swiftly 
74 compound and cascade, until gross failure ensues. Watch the CPU Idle % 
75 numbers.
76
77 I learned to split the testing into two modes: one for just call call processing
78 power, in the which we had relatively few simultaneous calls in place,
79 and another where we allow the the number of simultaneous calls to quickly 
80 reach a set maximum, and then rerun sipp, looking for the maximum.
81
82 Call processing power is measured with extremely short duration calls:
83
84     ./sipp -sn uac 192.168.134.252 -s 12 -d 100 -l 256
85
86 The above tells sipp to call your asterisk test machine (192.168.134.252)
87 at extension 12, each call lasts just .1 second, with a limit of 256 simultaneous 
88 calls. The simultaneous calls will be the rate/sec of incoming calls times the call length,
89 so 1 simultaneous call at 10 calls/sec, and 45 at 450 calls/sec. Setting the limit
90 to 256 implies you do not intend to test above 2560 calls/sec.
91
92 Sipp starts at 10 calls/sec, and you can slowly increase the speed by hitting '*' or '+'.
93 Watch your cpu utilization on the asterisk server. When you approach 100%, you have found 
94 your limit.
95
96
97 Simultaneous calls can be measured with very long duration calls:
98
99 ./sipp -sn uac 192.168.134.252 -s 12 -d 100000 -l 270
100
101 This will place 100 sec duration calls to Asterisk. The number of simultaneous
102 calls will increase until the maximum of 270 is reached. If Asterisk survives
103 this number and is not at 100% cpu utilization, you can stop sipp and run it again
104 with a higher -l argument.
105
106
107 By changing one Asterisk parameter at a time, you can get a feel for how much that change
108 will affect performance. 
109
110