Introduction

The J2EE specification defines the packaging of J2EE applications as a file with an EAR (Enterprise Archive) filename extension, and specifies that these applications be independent of each other. However, the specification is silent on how best to deploy applications. Should one choose to deploy a single J2EE application (EAR file) on each application server? Or should one deploy multiple J2EE applications (EAR files) on a single application server?

IBM ® WebSphere® Application Server supports both options. Which approach should you choose? This article explores many of the issues that you need to consider for both options. When reading this article, keep in mind that an EAR file can consist of one or many WAR (Web Application Archive) files (the criteria for packaging WAR files into an EAR file is a separate discussion and is not covered in this article).

Back to top

Performance

In general, the smaller the quantity of processes (application servers, HTTP server processes, etc.) you have on a machine, the less likely it is for swapping, paging, or context switching to occur on that machine. The expected result is that the operating system will devote fewer resources to process management, thereby allowing more system resources to be used for processing application workload. This improves application performance.

Consider a scenario where there are 20 applications; in this case, you would create 20 application servers, one for each application. If each server has a Java heap of 256 MB, then the memory requirements for the application servers would require at least 5 GB of memory. In the extreme case, if a large number of applications are deployed to a node, application servers will have to be shared; otherwise, the physical memory will be exhausted. CPU resources can also be a limiting factor in this scenario, although this is typically a concern only when machines are fully loaded (defined as more than 85 percent of CPU in use) as significant CPU cycles could be expended by process-level housekeeping tasks. Of course, the cost of process management usually becomes an issue only when running close to the memory or CPU limit for a given machine. Fortunately, it is standard practice for most organizations to run production servers at 50 percent CPU utilization in order to allow for workload spikes or outages, so this extreme scenario seldom occurs.

As an example, consider this simple test case where two applications were running under varying loads when deployed on individual application servers and then on a single application server. All tests were run on a 2 CPU HP-UX server with 2 GB of RAM that was running iPlanet 6.01 and WebSphere Application Server 4.03 Advanced Edition. A separate server was used for the Oracle 8.1.7 database.

From the above test case, you can see that using a single application server to run both applications results in a significant performance improvement, varying from 9.6 to 18.7 percent improvement. While each application shows a positive performance impact, the amount varies as a result of the different workloads imposed by each application. Application A performs several database selects and one update for each request, while Application B performs only one or two database selects per request, with an update occurring once every eight to 10 requests. In any case, for environments with high volume applications where performance is important, the performance benefit of reducing the number of application servers is significant. Combining applications into shared application servers gives one more effective application performance for the same operating system resources. It is important though that you always test in order to ensure that this is true for your environment.

Back to top

Performance testing and problem determination

To realize the possible performance benefits that a single application server can provide, you should test performance and scalability in two ways. First, test with a single application per application server in order to validate the performance and scalability for a given application, removing any application bottlenecks specific to that application. Second, test in conjunction with all of the other applications that will be deployed on the same application server. Additionally, keep in mind that testing multiple applications at once represents a more complex scenario than testing applications individually. Multiple scripts are required for load testing, one for each application to be run simultaneously. Systematically testing pre-production multiple systems is crucial for flushing out problems that may be caused by applications sharing application servers.

If you choose to deploy multiple applications on a single application server and performance issues occur, it might be more difficult to determine the offending application. Fortunately, you can use many of the performance monitoring tools that WebSphere Application Server provides, as well as those offered by third parties for this purpose.

Back to top

Application scalability

In some cases, an application developer might choose not to follow the application development best practices as outlined in Harvey Gunther's WebSphere Application Server Development Best Practices for Performance and Scalability. Because of the size of the HTTP Session object, you may be limited in your deployment choice. Some of you might have encountered applications where the size of the HTTP session object required the deployment of a single application per application server but also the creation of multiple clones. In the extreme case, this is necessary when memory requirements for session objects consume or even exceed the available JVM heap. For example, with a 1.0 MB HTTP session object and 1,000 connected users, the memory requirements are 1.0 GB (1000 x 1.0 MB) for the session objects alone. Of course, you can change the amount of sessions stored in memory, but then depending on the configuration, the session objects are either written to overflow or to the database. Both options have performance impacts, especially in the case of large session objects. Other application bottlenecks can also require the use of multiple application servers (clones) for a single application simply to meet scalability and performance requirements.

Back to top

Operational control and maintenance

When choosing to run two J2EE applications (for example, Application A and Application B) on a single application server, you should consider the following issues.

Does the same person have authority to stop all applications running on the application server? Although WebSphere Application Server lets you start and stop individual applications inside an application server from both the administration console and wscp, an organization still needs to consider how to assign operation control.

For some changes (for example, security changes) to take effect, you need to restart the application server. If two or more applications share an application server, this can lead to conflicting needs. Also, all applications on the same application server run under the same OS identity. This has security implications, since file permissions associated with the applications on an application server are owned by that OS identity. In this case, the files associated with one application cannot be protected from access by other applications on that application server because they share the same operating system privileges. If this is not acceptable, you would need to set up an application server per application in order to provide security protection.

How does an organization intend to handle application upgrades? Considerations include the control of application builds as well as control over an application server process. Since an EAR is not just a deploy-time component, but also a build-time component, there may be dependencies on who can trigger a build. While it's generally recommended that an EAR be totally self-contained, the fact is that this isn't a requirement and in many cases this isn't the case. It is not uncommon for EJBs or servlets in one EAR to depend on EJBs in another EAR with access through the global JNDI name space. As previously noted, WebSphere Application Server lets you stop and start individual applications, but in some cases an application upgrade may require you to start and stop an entire application server. Is an organization willing to stop or start an entire application server running multiple applications to perform an upgrade or do they wish to do this on an application-by-application basis? It is easier to do this if you have an application server for each application, but you can also do this with multiple applications on a single application server.

Applications themselves can introduce conflicting needs by requiring the user to place certain items in the JVM classpath or to set global JVM system properties. Selecting classloader visibility can also introduce deployment incompatibilities, such as the use of server visibility when an application employs a monolithic singleton. Deploying two or more applications with such an architecture in a single JVM would not be possible with server visibility. Keys Botzum and Rick Robinson discuss deploying and packaging applications, and selecting the classloader in more detail in J2EE Packaging and Common Code and Developing and Deploying Modular J2EE Applications with WebSphere Studio Application Developer and WebSphere Application Server respectively.

In the extreme case, a poorly written application can cause the JVM to hang or fail, thereby affecting other seemingly unrelated applications. Consider the case where a poorly written application starts many threads or consumes much memory or other shared resources such as database connections. In this example, there are several possible situations in which an application can take over an application server and starve other applications. Likewise, the performance characteristics need to be compatible. In fact, it took this author quite a bit of time and effort to tune the two applications used for the performance testing portion of this article. You can only identify and remedy application or resource conflicts through systematic testing and careful planning.

Back to top

Failover and workload management

Application deployment is also dependent on failover requirements. WebSphere Application Server 4.x provides for failover and workload management definition via server groups. A server group supports the clustering of a series of application servers. Consequently, you would only want to group applications into the same application server or server group that had similar needs for scalability and/or failover.

Consider the deployment alternatives depicted below in Figure 2. Which provides for failover?

In this scenario where this is only one application per application server, the failure of an application server results in the loss of service for the application associated with the application server. Keep in mind though that most environments recognize that neither of the deployment options depicted above is truly fault tolerant since the loss of a single physical server creates an outage. A more typical scenario is depicted below in Figure 3. This deployment scenario eliminates the physical server as a single point of failure. For more information on planning and implementing a high availability environment with WebSphere Application Server, refer to Modjeski et al's white paper, Failover and Recovery in WebSphere Application Server Advanced Edition 4.0.

Back to top

Conclusion

While this author favors sharing a single JVM/application server among multiple J2EE applications, there are many cases where this might not be practical. A more productive approach for many organizations would be to deploy one application per application server, spending time concentrating on optimizing individual application performance. Additionally, in some cases, an application will require its own JVM as a result of either operational requirements or application design.

Generally, mission-critical or large applications might want to deploy in their own JVM for the above reasons, while smaller or less important applications or interrelated applications (Human Resources applications, particularly those that share the same types of back-ends) might want to share JVMs. For example, all Siebel applications might want to share one JVM, so if Siebel goes down, then only these applications are affected.

Sharing application servers for multiple J2EE applications generally improves performance, particularly for large environments with many applications. However, this comes at a cost in operational flexibility compared to running one J2EE application per application server. As is the often the case, there are tradeoffs involved and the choice will depend on how an organization intends to manage their applications, their security requirements, the skill of their personnel for application administration and application design, application availability requirements, and the maturity of their processes.

Acknowledgments

The author would like to thank Keys Botzum, Kyle Brown, and Bill Hines for their comments and suggestions in preparing this article.

Back to top

Download

Information about download methods          Get Adobe® Reader®

Resources

• The J2EE specification
  
  
• J2EE Packaging and Common Code
  
  
• WebSphere Application Server Development Best Practices for Performance and Scalability
  
  
• Developing and Deploying Modular J2EE Applications with WebSphere Studio Application Developer and WebSphere Application Server
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Performance
• Performance testing and problem determination
• Application scalability
• Operational control and maintenance
• Failover and workload management
• Conclusion
• Download
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers