Benchmark of BEA WebLogic SIP Server on Intel Xeon Processor

by David Verbeiren and Stefano Gioia, Martin Lloyd, Scott Mordue
10/02/2007

Abstract

To benchmark the BEA WebLogic Communication Platform on the latest Intel server platforms, a straightforward benchmarking exercise was undertaken at the Intel laboratories in Kontich, Belgium. The purpose of this benchmark was to measure the performance, throughput, and latency that can be achieved by running a combination of BEA WebLogic SIP Server and the BEA JRockit Java Virtual Machine on a server platform based on Intel Xeon Processors featuring the new Intel Core microarchitecture.

This effort is part of a larger joint project between BEA and Intel to validate and improve the performance of BEA WebLogic SIP Servers on next-generation Intel architecture server platforms.

The Benchmark

The executed benchmark measures the SIP processing performance of the System Under Test (SUT) by executing a SIP scenario based on the SIPstone "Proxy 200" test case. SIPstone provides a "set of metrics for evaluating and benchmarking the performance of SIP proxy, redirect, and registrar servers." The open-source SIP load generation tool SIPp is used as a stimulus system placing calls through WebLogic SIP Server and answering them at the other side. Figure 1 depicts the SIP scenario executed.

The SIP scenario
Figure 1. The SIP scenario

A very simple SIP servlet application is deployed on the application server. This SIP servlet simply proxies the calls it received from the User Agent Client (UAC) simulator to the destination specified in the To header of the received INVITE message and which corresponds to the SIPp client acting as the User Agent Server (UAS). You can download a copy of the application.

The 100 Trying, 180 Ringing, 200 OK and ACK messages then complete the session setup. Call durations of 0, 40, and 80 seconds were tested in order to ascertain the impact of the proxy server having to maintain SIP call session information. As high throughputs were targeted and, to limit the number of SIP sessions that the SIP servlet proxy application and BEA WebLogic SIP Server have to maintain, instead of relying on the internal timeout of SIP sessions, the servlet invalidates the sessions as soon as the 200 OK response to the BYE message traverses the proxy.

To ensure consistent results, the BEA WebLogic SIP Server is restarted before each benchmark run, and a predefined warm-up sequence is executed whereby an increasing SIP call rate is applied to the SUT. This ensures code optimizations have been performed by the JRockit Java Virtual Machine before the actual benchmark starts.

After this warm-up period, a steady load at the target call rate is maintained for a period of one hour. During the test, session setup times and CPU utilization data of the SUT are collected. The data is then post-processed to compute the ninety-fifth percentile of the session setup time, as well as the average CPU utilization figure (total on all cores).

A benchmark run at a certain call rate is considered valid only if 95 percent of the calls have a setup time (INVITE to 200 OK, as measured at the UAC) lower than 50 milliseconds.

Test System Configuration

The test system consisted of two servers running the SIPp UAC and UAS emulators and a Gigabit Ethernet switch connecting them to the SUT, as shown in Figure 2.

High level system configuration
Figure 2. High-level system configuration

System Under Test

The system under test consisted of an Intel Server Board S5000PSL with a system bus speed of 1333 MHz and 8GB ECC FBDIMMs. The board was populated with two Dual-Core Intel Xeon Processor 5100 Series running at 3.0GHz. Network connectivity was provided by dual Intel Gigabit Ethernet interfaces.

Throughout this benchmark, WebLogic SIP Server 3.1 was executed on top of the BEA JRockit JVM R27.3.1 32-bit.

The operating system used was Red Hat Enterprise Linux 4 Update 4 64-bit.

The Dual-Core Intel Xeon Processor 5100 Series is based on the new Intel Core microarchitecture, an innovative microarchitecture that integrates a more efficient pipeline and memory architecture design to provide greater processor throughput with power management technologies that reduce power consumption without impeding performance.

The BEA JRockit JVM is a high-performance Java virtual machine (JVM) developed to ensure reliability, scalability, manageability, and flexibility for Java applications.

BEA WebLogic SIP Server is the industry's first converged Java EE-SIP-IMS-SOA application server, delivering high availability, reliability, scalability, and performance. It is the IMS-SIP application server component of the BEA WebLogic Communications Platform family of network middleware. A robust global ecosystem of NEP, SI, and ISV partners have standardized on BEA WebLogic SIP Server as the IMS-SIP foundation for next-generation communications.

BEA WebLogic SIP Server integrates SIP Servlet technologies with J2EE 1.4 and 1.3 and other leading Internet standards to provide a reliable framework for developing highly available, scalable, and secure telecommunications applications. BEA WebLogic SIP Server's seamless integration of disparate, heterogeneous platforms and applications enables your network to leverage existing software investments and share the enterprise-class services and data that are crucial to building next-generation telephony applications.

BEA JRockit Configuration

The JRockit JVM used in these tests is the currently available version JRockit R27.3.1, in conjunction with the following command-line parameters:

-Xmx3500m -Xms3500m

This specifies the maximum, as well as initial and minimum, heap size. This is the maximum heap size available with the 32-bit version of the JRockit JVM. However, it proved sufficient for the application.

-Xgc:gencon

The command-line option -Xgc determines the type of garbage collector used by the JVM. In this case, we used the generational concurrent garbage collector, which divides the available heap into two or more areas called "generations." Instead of allocating objects in one single space and garbage-collecting that whole space when it gets full, most of the objects are allocated in the "young generation," called the nursery. As most objects die young, most of the time will be spent collecting only from the nursery and not from the entire heap. A generational concurrent garbage collector, with an appropriately sized nursery and a concurrent collector algorithm (for both mark phase and sweep phases), is an excellent choice for low latency applications, typically found within telco applications.

-XXnosystemgc

system.gc()
-XXnocompaction

-Xns40m

-XXtlasize:min=3k

-XXkeeparearatio=0



BEA WebLogic SIP Server configuration

The version used for this benchmark is WebLogic SIP Server 3.1, and the following parameters were changed from their default values:

  • WebLogic SIP Server Transport queue size: 50000
  • WebLogic SIP Server Overload Protection onset queue length: 40000
  • WebLogic SIP Server Overload Protection abatement queue length: 5000


Pages: 1, 2

Next Page »