1.Follow the performance queue theory when tuning. The bottom line here is to efficiently balance the availability of system resources vs. the work to be done for optimal application response time. The rule of thumb followed is the amount of requests that can be processed at the Web Server tier must be higher than the requests that can be processed at the Application Server’s Web Container level. Further, the number of requests that can be processed at the EJB container must be less than the Web container level however this number must be greater than the number of requests that can be processed at the JDBC connection pool or other enterprise integration endpoints.
2.Size the JVM appropriately. This is the most difficult task in the application performance tuning exercise. However keep in mind that large heap memory does not necessarily mean better performance. Sizing of the JVM also involves choosing the appropriate garbage collection algorithm. Typically parallel garbage collection algorithms perform better.
3.Tune the Web Server with appropriate thread pool size, this number (across all web servers) should be large enough to accommodate all your requests per your traffic needs and make them wait at the Web Server tier when busy or greater than the anticipated number of requests.
4.Size the JDBC connection pool appropriately. The idea is to reduce the time/resources required when creating a connection. For example, Websphere and Weblogic application servers provide initial and maximum connection pool size, by setting the initial size to a number greater than zero will help. However such numbers are application architecture specific and must be found from stress testing. Enable caching of prepared statements on the JDBC Connection Pool.
5.If your application utilizes point to point (PTP) messaging and order of message processing is important then obviously Message Driven Beans (MDB) for processing inbound messages limits scalability. For example if the messaging provider is Websphere MQ, such scalability issues can be alleviated by using simple POJO’s based on file system look up for MQ objects.
6.If your application is data intensive then consider having a caching layer, for example Gigaspaces IMDB. Such decisions are better off when made during the application architecture design phase, rather than, retrofit it when performance problems are observed.
The above mentioned are some of the tuning tips applicable to a Java enterprise application however is not comprehensive list. Some of the other important components of an enterprise application tuning involve tuning of network, operating system, database, messaging platform and edge tier components such as Content Delivery Network and H/W load balancers. These must be tuned as well for best results.
Other articles/postings of possible interest:
1. Top five Java application performance management tools
2. To scale out or not using Gigaspaces
3. AdventNet, one product for all performance/service management needs