sipX System Performance

So far the sipX 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.

...

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)

...

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).

Test Results sipX Media Server

Even though the call control processing is typically co-resident with the media server, it has very little impact on the media processing performance except in extreme cases with very high call rates.

The media server is heavily multi-threaded and therefore profits in a direct way from multiple CPUs or cores. Media server uses integer arithmatic only and therefore does not require floating point math. We estimate that on a Sun UltraSPARC T1 CPU with 8 cores and 32 parallel threads performance would about triple as compared to an Intel dual core system.

Media server requires sufficient memory to perform well. On a 1GB single CPU system it will max out at around 20 simultaneous calls.

We ran up to 40 call scripts against the Media Server on our single CPU server with 2 GB of RAM so that there were 30 simultaneous media server calls at all time (MOS score >= 4).

Test Results sipX Configuration Server

sipX Config Server is a Web application. It's performance primarily depends on the number of users and devices stored in the database. As long as only a few hundred elements are stored in the database, performance is not significantly impacted. However, if Config Server is used to manage more than 1,000 users performance considerations become important. See XCF-944 for single, biggest performance issue.

For release 3.2 tests are conducted to assure adequate performance from the admin's perspective using a browser. Config Server was populated with up to 7,000 users and their devices. With that many elements managaed by Config Server the performance of the search function also is important and was included in the tests.