No matter how well written your business logic, when you deploy it to the middle tier, you will need to tune the application server runtime environment to maximize performance.
Like a vintage stereo with oodles of knobs for tweaking sound quality, application servers from vendors such as BEA, IBM, and Oracle, supply a dizzying set of controls. The trick is to turn the knobs just the right way, depending on the attributes of your application.
For example, if your application is servlet-heavy, you’ll want to enable servlet caching. Likewise, if your application uses many SQL statements to support a large user base, you’ll want to enable prepared statement caching and set the maximum size of the cache so it’s large enough to support the intended workload.
One of the major areas where performance tuning can really help is with the database connection pool. Set the minimum or maximum connections too low and you’re certain to create a bottleneck. Set them too high and you’ll likely see a slowdown resulting from the added overhead needed to maintain the larger connection pool.
If you know the intended workload, tune the application server runtime by turning on performance monitoring tools such as IBM’s Tivoli Performance Viewer for WebSphere on a staging application server. Generate the amount of workload that you expect by using a load-generation tool, then save the monitoring results and play them back to analyze which knobs need adjusting.
When in production, it’s a good idea to turn on low-overhead, passive monitoring to keep tabs on the runtime. If your workload changes over time, you’ll want to execute a fresh performance review.