Benchmark Test of OpenSER

The purpose of this benchmark test was to determine the call capacity of OpenSER V1.3 and RTPproxy V1.0 running on a single server. The test, designed to replicate a production environment for wholesale VoIP operations, was performed in the TransNexus lab.

  • Test Bed

    The host server for OpenSER and RTPproxy was a Dell Precision 490 server with two Intel Xeon 5140 dual core, 2.33 GHz CPUs and 4 GB of RAM. Three CPU cores were disabled for the test. The test was run using just a single CPU core. Multiple SIPp clients directed traffic to OpenSER which queried an OSP server for call routing instructions. The test was designed for each call to require an average of two retries before the call was completed to a SIPp server on the third try. The two-way RTP stream for each call flowed through the RTPproxy. Call Detail Records for each call attempt were sent from OpenSER to the OSP server.

OSP Server RTP Proxy

  • Test Results

    OpenSER and RTPproxy, running on a single core of a 2.33 GHz CPU can manage up to 750 simultaneous calls. The chart below plots the test data for CPU utilization as a function of simultaneous calls.

CPU Utilization

  • Performance Results for OpenSER and SIP Express Router

    We often hear the questions:

    • How fast are OpenSER or SER in a real world environment?

    • How do SER and OpenSER compare?

    We decided to answer these questions and created a detailed performance test for OpenSER and SIP Express Router.

    To simulate a production environment, the SIP proxy under test queries an external OSP server for routing information on each and call and then reports call detail records to an external OSP server. Five destinations are returned to the SIP proxy for each call in random order. Four of the five destinations simulate call failure scenarios so the SIP proxy must retry the call an average of two times before the call is completed. These tests were performed on a single core of an Intel Xeon 5140 2.33 GHz CPU.

    Here is a brief summary of what we learned.

    • The performance of OpenSER V1.2 and SER 2.0 are not materially different, however, there are two minor differences.

      1. SER V2.0 requires less memory.

      2. OpenSER V1.2 has less post dial delay.

    • By all measures, OpenSER V1.2 is significantly better than OpenSER V1.1.

    For production operation (with call retries and CDR reporting), we suggest the following simple guideline for sizing server hardware to operate at 60% CPU utilization for OpenSER V1.2 and SER V2.0:

    • One GHz of CPU processing capacity can manage 60 calls per second.

      For example, a server with two, dual core, 3.0 GHz CPUs would effectively have (2 CPUs * 2 cores * 3 GHz per CPU) twelve GHz of CPU processing capacity. This server, hosting either OpenSER V1.2 or SER 2.0, would be able to manage 720 calls per second at approximately 60% CPU utilization.

    • CPU Utilization

      The following chart plots CPU utilization as a function of calls per second. The results for OpenSER V1.2 and SER 2.0 are identical. The performance of OpenSER V1.2 is 13% better than OpenSER V1.1.

CPU Utilization Diagram

  • Memory Usage

    Memory is not a major resource requirement, even at high loads. SER 2.0 has the lowest memory requirement.

Memory Usage Diagram

  • Post Dial Delay

    The data on the following chart is an indirect indication of Post Dial Delay (PDD). The data presented is the percentage of calls in each test that experienced a PDD greater than six seconds.

Post Dial Delay Diagram

  • Call Completion

    The following chart presents the percentage of calls which were not completed successfully for each test. When CPU utilization was less 90%, both OpenSER V1.2 and SER 2.0 completed all calls successfully.

Call Completion Diagram