We have covered in some detail the importance and the mechanisms to avoid having the network, the database system, or the driver/emulator to be the bottleneck. That condition is necessary in order for us to optimize the performance on the application server. The steps we talked about are sometimes very tedious and time consuming, but without these steps to make sure the other systems are not the bottlenecks, performance gains on the application servers may not be measurable. We do not advise people to take short cuts to only work on the application server when trying to optimize the performance of their applications.

Application-server tuning and optimizations can come from several areas of improvement:

• Deployment descriptors–Different application servers enable different ways to use the application servers to run with the application in the form of deployment descriptors. We found that in the case of our workload, the max-beans-in-cache values for stateful session beans need to be monitored for optimal performance. The use of memory to reduce the number of passivations of EJB is usually a good tradeoff. Relationship caching and nested relationship caching for entity beans can reduce the number of round trips to the database servers. The choice of optimistic concurrency vs. pessimistic concurrency is not always clear and often requires measurements to determine how often collisions between transactions seeking to operate on the same data occur. While a detailed methodology for making this decision is outside the scope of this paper, optimistic concurrency is suited to those occasions where such collisions will rarely occur, while pessimistic concurrency employs additional locking mechanisms under the assumption that such collisions will be more frequent.
  
  
• Choice of JDBC drivers–The choice of JDBC drivers is important. While in general, a type 2 driver will tend to shift the work done on the database server to a native client on the application server, the complex relationship often requires measurement to make sure. Using a type 2 driver may help multiple application servers to share a single database, but we found it not to be ideal for our workload analysis, as we need to max out the CPU utilization on the application server. Early measurements also indicated approximately a 5-10% performance gain for one configuration after changing the JDBC driver from type 2 to type 4. The choice of the database back-end systems can also restrict the choice of JDBC drivers within the same type (e.g. type 4 thin drivers). An application server can support multiple third-party JDBC drivers to choose for optimal performance for a particular application. Our measurement indicated that the performance difference between two very competitive JDBC drivers can reach 25%.
  
  
• Application-server configurations and run-time parameters–Different application servers may provide specific optimization for a platform. For example, BEA WebLogic* Server has performance packs optimized for network I/O in native mode. Whenever possible, such performance packs should be used. For BEA WebLogic* Server, this can be done by setting NativeIOEnabled="true“ in config.xml. The performance gain can be quite significant, depending on the network activity and the interaction with the OS. BEA WebLogic Server supports the concept of thread queues, where each queue can be assigned for a group of activities. This is useful for exploring balancing the response times among a few groups of transactions, as assigning more threads to a queue would likely reduce the response time of that queue. Simply increasing every thread queue, however, would increase the total number of threads on the system and will generally have an adverse impact on performance. The adjustment of thread queues often demands careful design of experiments to study. We found that the performance tends to suffer when the total number of those threads needed is outside the range of 50 to 100 on the Windows system. It is important to have a one-to-one mapping between the worker threads and the JDBC connections for optimal performance. The parameter “StatementCacheSize” avoids recompiling statements that are already in the cache. We found that the performance is relatively insensitive to this parameter, so long as it is within the range of 50-300.

Application-server vendors often provide performance analysis tools such as WebLogic Console for a GUI interface to study the queuing of requests, the utilization of EJB caches, etc. These measurements should be part of the iterative data-analysis process. For batch processing, tools are also available to collect such statistics without going through the GUI interface. A detailed discussion* of such tools can be found on the BEA Web site.

This article covers only a few items that affect workload performance. Other items may be more important for different workloads. The best way to find out is to gain knowledge of the systems and apply the top-down data-driven methodology to find out which ones are good for a particular application.