Many developers who have designed, coded, tested, and deployed Java 2 Enterprise Edition (J2EE) applications have learned the hard way that not all J2EE features perform effectively under heavy production loads. One must consider a number of variables during each phase of the IBM WebSphere "build, deploy, manage" life cycle to ensure that enterprise J2EE applications are robust and scalable.

Failure to address key J2EE behaviors in a runtime environment can cause performance slowdowns for specific user requests once Web site traffic exceeds a specific performance threshold.

In order to support today's dynamic e-business infrastructures, developers require a knowledge of J2EE that goes beyond simply understanding how to create syntactically correct Java code. There is no single knob to turn or parameter to tweak that will automatically increase the performance of a Web site or scale a J2EE application. Rather, development teams must use proven best practices to support application functionality and business performance requirements. Failure to adopt common development standards that address the entire WebSphere life cycle may cause developers to spend costly resources recoding or re-architecting J2EE applications to achieve the desired performance.

This article explores best practices for using server cloning techniques to increase application performance efficiency while providing the redundancy required to support business-critical applications.

Application Server Clone Overview
Optimizing a WebSphere Application Server for a specific application and infrastructure environment can take a significant amount of time and effort. Once a WebSphere Application Server and its J2EE application is tuned, however, organizations can quickly expand their Java environments by creating copies of these applications, called clones. The J2EE application clones each run as a separate instance inside their unique Java Virtual Machines (JVMs). Organizations can use clones to increase the performance of a specific server and provide the failover necessary to support business-critical applications. The WebSphere Application Server administration system allows users to create and manage cloning features.

The original tuned application server has a template, called a group, that acts like a stamp to create additional clones. Clones have the same structure as the original server group and may include servlet engines, Enterprise JavaBean (EJB) containers, servlets, etc. Server clones have the same properties as traditional J2EE objects: they receive requests from HTTP Web servers, automatically process requests, and are connected to databases. Additionally, if one clone fails, WebSphere Application Server automatically routes commands to a second clone.

There are two cloning methods: vertical and horizontal. Each method serves a distinct purpose and has a unique set of implementation considerations. Requests are routed to each clone through the HTTP Web server, along with the WebSphere Application Server plug-in. The decision to route requests via round-robin or load balancing can be made at runtime. Also, the WebSphere Application Server plug-in will maintain session affinity between application server instances and will provide failover support if one of the instances fails.

Vertical Clones
Vertical cloning refers to the process of creating multiple copies of an application server on a single physical machine. Through vertical cloning, users can increase the performance of a single machine without increasing the complexity associated with managing multiple JVMs. The inherent concurrency limitations within a single JVM process typically cannot capitalize on the full processing power of application servers, especially when a single JVM is deployed on a large multiprocessor machine. To overcome this challenge, vertical clones are installed to enable organizations to use the full CPU power and memory of the application server hardware (see Figure 1).

 

Organizations typically deploy between three and five clones on a single machine. Because each clone uses computing resources, adding too many clones to a single machine will consume too much memory and CPU power, and actually hinder application performance. Each J2EE application requires 1GB of heap space; running three clones on a single machine increases the memory requirements to 3GB. It is important to note that vertical clones create a single point of failure because the clones are located on a single machine. If there is a hardware or database connectivity problem, vertical cloning is not structured to provide failover or redundancy support on other machines.

There are, however, significant advantages to vertical cloning. The ability to centrally manage vertical clones enables organizations to quickly add processing power without additional management requirements. Central management enables administrators to make a single update to the server group, which is applied automatically to each vertical clone. This feature enables administrators to quickly and efficiently control all JVM processes running on a single application server. It is important to note that the server group is a representation of the multiple server clones, but is not a working application server and does not run inside its own JVM process. As such, the server group does not have any application server capabilities.

Horizontal Clones
Horizontal cloning addresses the critical requirement for application failover. Rather than maintaining clones on a single machine, horizontal cloning enables organizations to deploy clones of a tuned application to multiple machines (see Figure 2). If one server shuts down, an application clone on a second server will automatically stand in for the unavailable server. The placement of application clones across the enterprise also enables organizations to distribute performance load across multiple machines. By creating additional J2EE objects, horizontal cloning also provides additional throughput across the enterprise.

 

Placement of horizontal clones across the enterprise is an important consideration. Organizations that do not appropriately address the role of EJBs in a J2EE environment may experience performance delays that may be exacerbated, in part, by horizontal cloning. IT managers must, for example, architect and deploy EJBs to ensure that user requests are calling only servers that contain EJBs, or ensure that specific requests are routed to the appropriate EJBs. Similarly, an application server architecture that directs requests to EJBs that can be executed by smaller servlets will cause EJBs to be overtaxed, while other J2EE infrastructure, such as servlets, will be underutilized.

Because each horizontal clone is located on a different physical server, communication among the servers consumes network resources. As such, the number of horizontal clones may negatively affect application performance. The impact of increased network traffic associated with horizontal clones will depend on application and hardware variables for each organization.

Additionally, management of horizontal clones can be complex. Unlike vertical cloning, where administrators make changes to the clones through groups, administrators must make updates and changes to each horizontally cloned machine group that represents the application. IT administrators typically first make changes to one machine in a group. The updated file from the first machine is then transferred to the other machines that are horizontally cloned. In this case, IT managers need to update only unique machine-characteristic information included in the file - such as server names and directory paths.

In real-world applications, organizations typically deploy both vertical and horizontal clones. Organizations should typically install vertical clones first to increase performance. As noted, it is important to monitor the impact that each additional clone has on CPU and memory overhead. After optimizing performance on each server using vertical cloning, organizations should then deploy horizontal clones.

The failover and redundancy that horizontal clones provide is integral to supporting today's business-critical Web environments. Also, by vertically and horizontally cloning J2EE applications, organizations will be able to maintain 24x7 uptime when upgrading or redeploying new J2EE code. Horizontal cloning enables organizations to shut down one application server and have all requests automatically routed to a second application server. When the new machine comes back online, the same process is performed on the next horizontally cloned machine.

The Role of the HTTP Plug-in in Server Cloning
The WebSphere Application Server HTTP plug-in plays an integral role in automatically routing requests between servers, maintaining sessions, and ensuring session affinity when requests are rerouted among machines. The WebSphere Application Server plug-in is generated and deployed to an organization's unique HTTP Web server. The WebSphere Application Server plug-in directs requests from the HTTP Web server to the appropriate application server. The plug-in uses an XML configuration file (plugin-cfg.xml), generated by the administrative server, to determine information concerning the WebSphere domain.

Each application server plug-in is assigned a weighted value, used to determine which application server will receive the next request. When the HTTP Web server is started, the WebSphere plug-in reads information from the plugin-cfg.xml file and stores an assigned server ID, along with a list of servers in the system. When a request enters the plug-in, it passes through the URL it receives from the client browser (e.g., http://www.candle.com/application1/servlet1). It separates this information into two pieces: the virtual host, e.g., www.candle.com:80; and the Uniform Resource Identifier (URI), e.g., /application1/servlet1.

The HTTP plug-in then looks in the XML file for a matching URL and URI. If successful, the plug-in then searches the XML file for a route entry containing the <UriGroup> and the <VirtualHostGroup> just retrieved. This entry is used to identify the cluster that will handle the request (see Listing 1). In this example, the cluster is "CandleCluster1." The cluster contains either a stand-alone server or WebSphere server clones. Once the cluster is identified, the plug-in must route the request to the appropriate server.

If the client request includes an HTTP session, the CloneID is retrieved from the end of the session ID. The session ID is checked against the CloneIDs in the server cluster until a match is found. The request is then routed to the appropriate server. If the request has no session ID, the plug-in will alternatively route the request to the next server based on the routing algorithm chosen. This process outlines how the plug-in and its configuration file determine server routing requests and maintain session affinity.

Conclusion
The importance of taking the time to tune an application server to support specific business requirements cannot be overstated. Once an application server is tuned, however, organizations will be able to use cloning to quickly scale the application server to support enterprise-wide computing requirements.