As mentioned in the introduction to this section, one chapter is hardly enough when it comes to detailing performance tuning. You would do well to perform some additional research, investigating tuning of Java applications, tuning operating systems, how capacity planning works across multiple servers and applications, and anything else that is relevant to your particular application. To get you started, we wanted to provide some resources that have helped us.
Java Performance Tuning by Jack Shirazi (O’Reilly) covers all aspects of tuning Java applications, including good material on JVM performance. It is a great book that includes information about developer-level performance issues in great depth. Of course, Tomcat is a Java application, so much of what Jack says applies to your instance(s) of Tomcat. As you learned earlier in this chapter, several performance enhancements can be achieved just by editing Tomcat’s configuration files.
Keep in mind that while Tomcat is open source, it’s also a very complex application, and you might want to be cautious before you start making changes to the source code. Use the Tomcat mailing lists to bounce your ideas around, and get involved with the community if you decide to delve into the Tomcat source code.
If you’re running a web site with so much traffic that one server may not be enough to handle the whole load, you should probably read Chapter 10—which discusses running a web site on more than one Tomcat instance at a time, potentially on more than one server computer.
You can find more web pages on capacity planning simply by searching for “capacity planning” on the Net. A couple of good examples are http://en.wikipedia.org/wiki/Capacity_planningand http://www.informit.com/articles/article.asp?p=27641&rl=1.
* There is also the server-side approach, such as running Tomcat under a Java profiler to optimize its code, but this is more likely to be interesting to developers than to administrators.
* Siege is not able to test with keep-alive connections turned on—a feature that siege is missing, at least as of this writing. This means that using siege, you cannot perform the highest performance benchmark testing, although siege also implements other types of testing that ab does not implement, such as regression testing and an “” mode, where it can generate randomized client requests to more closely simulate real web traffic.