sipX System Performance

So far the sipXecs project team has not been able to publish detailed performance test results. However, extensive testing has been done under different conditions and we also learnt a lot going through increasingly large production deployments exceeding 1,000 users. This page attempts to summarize some of the findings.

Factors that Affect Performance

Assessing overall system performance in a way relevant to a real deployment scenario is difficult for a variety of reasons:

*The actual traffic mix varies greatly: Not just between a call center and an enterprise, but also between different enterprises large variations in traffic mix are observed.
*Deployment options: Running all the different sipX components on one server poses the biggest challenge when it comes to assessing performace.
*Voicemail usage varies greatly: Some companies use lots of voicemail, tend to forward voicemail, and use distribution lists. Other companies hardly ever use voicemail for internal purposes.
*Other services: Usage patterns for call park services, voice conferencing services, ACD call center services, and the auto-attendant vary greatly.
*Reconfigurations: Using Config server to make configuration changes can affect performance during the necessary replication process.

Definition of a Relevant Traffic Mix

Like with any Telecommunications system assessing performance requires the definition of a relevant traffic mix. While traffic mix normally breaks down into mean call attempts per unit of time and mean call holding time, in a SIP system the call holding time is irrelevant when it comes to assessing performance of the call control system.

Of course it is assumed here that the SIP system under test follows the SIP standard and implements strict separation of signaling and media (or in other words: Media does not go through the call controller). If, for what ever reason, media does go through the call controller, as is the case with Asterisk, the definition of a relevant traffic mix with the objective of obtaining an accurate measure of performance becomes near impossible. This especially if the system also might get involved in media transcoding under certain conditions.

Call attempts per unit of time then consists of actual session invite, transfer, and refer transactions plus the registration and subscribe / notify transactions the phone initiates on its own in regular intervals. In order to discuss relative importance of the different elements that make up the traffic mix, let's consider the following example:

IP PBX phone system with 2,000 connected phones. Registrations are set to expire afte 3,600 seconds (default). It shall be assumed that every phone participates in 2 sessions per working day (0.25 calls per hour). This seems to be a reasonable assumption in many cases as the population of phones also includes phones in common areas that are hardly ever used. Given these assumptions our call controller would receive 500 session invites per hour, 2,000 registrations and 2,000 subscribe / notify requests. In this case registration and subscribe / notify transactions are about 90% of all transactions, which is not atypical.

Technical & Design Factors that Affect Performance

Knowing a systems technical characteristics allow you to choose the best possible hardware for a given situation:

*Media does not go through the sipX server: Media flows are routed directly between end systems and therefore do not affect performance. The only exception is when the sipX media and call park servers are installed on the same hardware.
*High-availability configuration: Using the new high-availability option that became available in release 3.2, performance of the call control system can effectively be doubled by using two servers that load-balance using DNS SRV.
*No media transcoding: sipX does not do any media transcoding. That's good for performance because transcoding is very heavy on CPU time.
*Multi-threading: Performance of sipX is positively affected in systems with several CPUs (HT or multi-core).
*No floating point math: Hardware setups with multiple integer cores, such as the Sun UltraSPARC T1 with up to 8 cores per CPU are expected to yield about a 3x performance improvement over Intel dual core CPUs.
*Server setup: The sipX server should be setup without an X server and with no graphical desktop.
*Physical memory: Swapping has to be avoided. The media server tends to profit from a large physical memory (up to 2 GB) if pushed to its performance limits.

Reference Test Platform

The test results presented below were obtained with rather modest hardware:

• HW: Dell PowerEdge 750 (single CPU 2.8 GHz HT, 1 GB DRAM, SATA HD)
• OS: RHEL 4 (Kernel 2.6.9 SMP)

Test Results sipX Communications Server (sipX proxy, sipX auth proxy, sipX registrar)

REGISTER: 10 cps (24 hrs, 99.986%)

On a dual CPU system you should expect a call rate of about 25 cps (unauthenticated) as compared to a single CPU system, which corresponds to 90,000 BHCC. In a high-availability configuration using a master and slave server (release 3.2) under normal operating conditions the two servers will load share, controlled by priority settings in the DNS SRV record. The call rate under such conditions, therefore, is expected to double to 50 cps (180,000 BHCC).

To put this in context: If every phone in your enterprise will participate in a call every 15 minutes on average (which is very high under normal conditions), the sipX call control system would accommodate traffic from 45,000 phones.

Registrations & Subscriptions: By default SIP registrations are set to expire after 3,600 seconds. Therefore, and in addition to processing calls, the sipX server has to have sufficient capacity to handle registration and subscribe / notify requests from the phones (e.g. subscriptions for message waiting indication (MWI) or presence including line state changes).