Enabling Java-based VoIP backend platforms through JVM performance tuning

Editor's Note: This article is adapted from "Enabling Java-based VoIP backend platforms through JVM performance tuning" published in the proceedings of the VoIP Mase '06 workshop, IEEE Catalog Number 06EX1301. Reprinted, with permission. © IEEE 2006.

Abstract

Software backend platforms are increasingly important in Voice over IP (VoIP) service offerings. Java and the J2EE platform have evolved as one of the important software frameworks for designing and implementing business logic on a telecom backend platform. Considering the popularity of Java, the question arises whether Java-based backend platforms can meet the requirements imposed by VoIP applications.

The Session Initiation Protocol (SIP) is an important example of a signaling protocol often used for VoIP. The SIP Servlet technology was developed for building Java based VoIP services. This article evaluates the performance of the BEA Weblogic SIP Servlet implementation. It describes the evaluation procedure and the results obtained. It also investigates the influence of Java Virtual Machine (JVM) tuning. In addition, the article demonstrates performance of techniques based on the obtained results, used to optimize the garbage collector tuning of the JVM in general, and more specifically for VoIP related applications.

Introduction

Telecom applications often have very strict requirements regarding throughput (for example, the number of VoIP call setups a soft switch can process per second) and latency (for example, the setup of a call should be very fast). These requirements may indicate that Java is not a good choice for this job as the behavior of the garbage collection and the virtual machine may conflict with the strict requirements.

The Java language is highly structured, strongly typed, and object oriented. It is not compiled to machine-specific instructions but to a byte code, which is then executed on a virtual machine, available for all sorts of platforms. Although this can result in a certain performance penalty, it does make Java highly portable. Another feature with important implications is the use of a garbage collector. Java includes automatic memory management (garbage collection) as a part of the Java runtime. This means many common errors made by developers related to memory management cannot occur. Since garbage collection is a part of the Java runtime, it is not under the complete control of the application developer; this also contributes to the performance penalty and complicates the predictability of garbage collection.

To make Java more attractive to the telecom industry the JAIN (Java APIs for Integrated Networks) initiative is providing an extensive set of standardized APIs to facilitate the development and deployment of telecom services. Although JAIN does offer open standardized specifications tailored for telecom applications, it does not directly address the issues of the Java garbage collection. This article proposes techniques to assist with tuning depending on specific requirements such as a minimization of the garbage collection pauses and latency or the minimization of the total execution time of the telecom services.

First we will briefly detail the selected use case for the performance evaluation. Next we will explain the relevant Java Virtual Machine internals, followed by optimization possibilities and tuning techniques. We then provide an overview of the test setup and the results of the performance evaluation.

A SIP Use Case

The Session Initiation Protocol (SIP) describes an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.

A more in-depth description of SIP, the SIP Servlet, and the Weblogic Communications platform can be found in the following Dev2Dev articles:

The Proxy 200 test, a typical use case for setting up a VoIP call, is shown in Figure 1. It was chosen for the performance evaluation in this article. We are interested in the time it takes to set up a call; this is the time it takes from the initial INVITE of Alice until she receives an OK from Bob.

Figure 1

Figure 1. Proxy 200 test

After this, Alice will send an acknowledgment to Bob saying she received the OK and the media session (for example, voice or video conference) can start. When benchmarking, no media session was initiated and the call was terminated immediately.

Java Virtual Machine Internals

The hardware platform used always has a great influence on performance and evaluation, but so does the Java Virtual Machine. Of great importance here is garbage collection and memory management. Garbage collection may lead to the whole virtual machine being paused. These pauses should not last too long in VOIP applications because a long pause could cause a timeout when setting up a call.

Java Virtual Machine memory

The heap of the Java Virtual Machine is divided in three major sections called generations as they correspond with the lifetime of the objects, as shown in Figure 2. The three generations are Young, Tenured, and Perm, and the sections marked Virtual are reserved but not physically allocated until necessary.

The Young generation consists of Eden and two survivor spaces. New objects are always created in Eden. One of the survivor spaces will be empty at all times and serves as a destination for the other one. When a garbage collection occurs, all live objects from Eden and the survivor space are copied to the other survivor space. Objects are moved between the survivor spaces until they are old enough to be moved to the tenured generation which holds the longer lived objects.

Figure 2

Figure 2. Structure of the Java Virtual Machine Memory

The Perm generation holds those objects that are live during the complete lifetime of the virtual machine. As a result this generation does not need to be cleaned by the garbage collector.

Java garbage collection strategies

Apart from the default garbage collector, two other collectors, the Parallel collector and the Concurrent Mark and Sweep collector (from now on referred to as the Concurrent collector), were evaluated. These collectors are available in the standard Sun Java Runtime Environment. Generally when a garbage collection occurs, the virtual machine will be paused and the garbage collector will do its job. The Parallel collector will spawn multiple garbage collection threads to speed up the execution of its task and minimize the pause of the garbage collection. This collector will work on the Young generation. The Concurrent collector works on the tenured generation and will partially run concurrently by the application. Although full garbage collection cycles are still needed, the cycles will be shorter as a result—though this does come at a small cost of using some processing power that could otherwise be used by the application.

The two collectors can be used together as they operate on different generations. This allows for a significant reduction of garbage collection-initiated pauses as shown in Figure 3.

Figure 3

Figure 3. The available garbage collectors