Tomcat优化详解

1          概述 
        本文档主要介绍了Tomcat的性能调优的原理和方法。可作为公司技术人员为客户Tomcat系统调优的技术指南，也可以提供给客户的技术人员作为他们性能调优的指导手册。

2          调优分类 
        由于Tomcat的运行依赖于JVM，从虚拟机的角度我们把Tomcat的调整分为外部环境调优和自身调优两类来描述。 
2.1      外部环境调优

调整Tomcat运行环境的操作系统参数和运行Tomcat的java虚拟机参数。 
2.1.1        JAVA虚拟机性能优化

Tomcat需要依赖Java虚拟机运行。根据客户选用的主机的操作系统选择对应的 JDK的版本。无论哪个厂商的JDK，都建议使用最新的版本。 
        虚拟机可通过命令行的方式改变虚拟机使用内存的大小。如下表所示有两个参数用来设置虚拟机使用内存的大小。 
        参数                               描述 
        -Xms<size>                JVM初始化堆的大小 
        -Xmx<size>                JVM堆的最大值 
        Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，需要调大。 
　　[LD1] Windows下，在文件tomcat_home/bin/catalina.bat，Unix下，在文件tomcat_home/bin/catalina.sh的前面，增加如下设置：
　　JAVA_OPTS=‘-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】’' 
       需要把这个两个参数值调大。例如：

1. JAVA_OPTS='-Xms256m -Xmx512m'

表示初始化内存为256MB，可以使用的最大内存为512MB。 
        另外需要考虑的是Java提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾可以接受的速度与应用有关，应该通过分析实际的垃圾收集的时间和频率来调整。
       如果堆的空间很大，那么完全垃圾收集（FULL GC）就会很慢，但是频度会降低。如果在客户系统中把堆的大小和内存的需要一致，完全收集就很快，但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。对于SUN和HP等虚拟机，推荐将最小堆大小和最大堆大小设置为同一值，因为这样可以避免浪费用于时常调整堆大小所需的 VM 资源。
        当然，客户系统如果用到IBM虚拟机，要特别的注意设置-Xms和-Xmx一样大小会耽误垃圾回收的开始直到堆满，这样第一次垃圾回收就会变成非常昂贵的操作。推荐把-Xms设置为应用所需的最小值，这样会产生高效的垃圾回收。

2.1.2        操作系统性能优化

以客户系统为HP-UX为例。 
HP系统中对Tomcat有影响的参数： 
其中： 
max_thread_proc: 一个进程所能创建的线程的最大数 
nkthread: 在系统上同时允许的核心线程的最大数 
maxfiles上表给的建议是不是不合适？ 
如果在输出里看到消息：java.lang.OutOfMemoryError: unable to create new native thread，则说明名为 max_thread_proc 的 Unix 内核设置过小。max_thread_proc 是单个进程中的最大线程数。 它必须大到能够容纳 Java 应用程序中的所有线程以及虚拟机本身中的部分额外线程。

查看核心参数：$ulimit -a

显示[LD2] 输出中的 nofiles 是指用户的进程能同时打开的最大文件句柄数。如果日志中出现”two many open files”的异常，需要重点检查这个参数。coredump 参数是 core 文件最大值的，限制当进程 coredump 时将产生 core文件的大小不能超过这个最大值。如果在日志文件检查时，发现 core文件不完整，需要增大这个参数值。执行 ulimit  -n 命令可以设置 nofiles 参数，执行ulimit -c命令设置 core 文件最大值。
        如果是在Windows操作系统上使用Tomcat，那么最好选择服务器版本。因为在非服务器版本上，最终用户授权数或者操作系统本身所能承受的用户数、可用的网络连接数或其它方面的一些方面都是有限制的。并且基于安全性的考虑，必须经常给操作系统打上最新的补丁。
2.1.3        Tomcat与其它web服务器整合使用

虽然tomcat也可以作web服务器,但其处理静态html的速度比不上apache,且其作为web服务器的功能远不如apache,因此我们想把 apache和tomcat集成起来，将html与jsp的功能部分进行明确分工，让tomcat只处理jsp部分，其它的由apache,IIS等这些 web服务器处理，由此大大节省了tomcat有限的工作线程[LD3] 。
2.2      自身调优 
本节将说明Tomcat性能调优的技巧和方法，这些技巧和方法与操作系统或Java虚拟机的种类无关。以下方法都是针对Tomcat 性能自身调整的最佳方式。 
2.2.1        禁用DNS查询 
        当web应用程序要记录客户端的信息时，它也会记录客户端的IP地址或者通过域名服务器查找机器名转换为IP地址。DNS查询需要占用网络，并且包括可能从很多很远的服务器或者不起作用的服务器上去获取对应的IP的过程，这样会消耗一定的时间。为了消除DNS查询对性能的影响我们可以关闭DNS查询，方式是修改server.xml 文件中的enableLookups参数值：
不同的tomcat版本稍有不同。 
Tomcat4

1. <Connector className=“org.apache.coyote.tomcat4.CoyoteConnector”port=“80”
2. minProcessors=“5” maxProcessors=“75” enableLookups=“false”
3. redirectPort=“8443” acceptCount=“100” debug=“0” connectionTimeout=“20000”
4. useURIValidationHack=“false” disableUploadTimeout=“true” />

Tomcat5

1. <Connector port=“80” maxThreads=“150” minSpareThreads=“25”
2. maxSpareThreads=“75” enableLookups=“false” redirectPort=“8443”
3. acceptCount=“100” debug=“0” connectionTimeout=“20000”
4. disableUploadTimeout=“true” />

除非客户需要连接到站点的每个HTTP客户端的机器名，否则我们建议在生产环境上关闭DNS查询功能。可以通过Tomcat以外的方式来获取机器名。这样不仅节省了网络带宽、查询时间和内存，而且更小的流量会使日志数据也会变得更少，显而易见也节省了硬盘空间。对流量较小的站点来说禁用DNS查询可能没有大流量站点的效果明显。

2.2.2        调整线程数 
        另外一个可通过应用程序的连接器（Connector）进行性能控制的参数是创建的处理请求的线程数。Tomcat使用线程池加速响应速度来处理请求。在Java中线程是程序运行时的路径，是在一个程序中与其它控制线程无关的、能够独立运行的代码段。它们共享相同的地址空间。多线程帮助程序员写出CPU最大利用率的高效程序，使空闲时间保持最低，从而接受更多的请求。
       Tomcat4中可以通过修改minProcessors和maxProcessors的值来控制线程数。这些值在安装后就已经设定为默认值并且是足够使用的，但是随着站点的扩容而改大这些值。minProcessors服务器启动时创建的处理请求的线程数应该足够处理一个小量的负载。也就是说，如果一天内每秒仅发生5次单击事件，并且每个请求任务处理需要1秒钟，那么预先设置线程数为5就足够了。但在你的站点访问量较大时就需要设置更大的线程数，指定为参数maxProcessors的值。maxProcessors的值也是有上限的，应防止流量不可控制（或者恶意的服务攻击），从而导致超出了虚拟机使用内存的大小。如果要加大并发连接数，应同时加大这两个参数。web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。

在Tomcat5对这些参数进行了调整，请看下表： 

        最好的方式是多设置几次并且进行测试，观察响应时间和内存使用情况。在不同的机器、操作系统或虚拟机组合的情况下可能会不同，而且并不是所有的web站点的流量都是一样的，因此没有一刀切的方案来确定线程数的值。

2.2.3        加速JSP编译速度 
        当第一次访问一个JSP文件时，它会被转换为Java servlet源码，接着被编译成Java字节码。客户工程师可以控制使用哪个编译器，默认情况下，Tomcat使用命令行javac进行使用的编译器。也可以使用更快的编译器，这里将介绍如何优化它们。
       [LD4] 另外一种方法是不要把所有的实现都使用JSP页面，而是使用一些不同的java模板引擎变量。 
       在Tomcat 4.0中可以使用流行而且免费的Jikes编译器。Jikes编译器的速度要高于Sun的Java编译器。首先要安装Jikes（可访问http://oss.software.ibm.com/pub/jikes 获得更多的信息），接着需要在环境变量中设置JIKESPATH包含系统运行时所需的JAR文件。装好Jikes以后还需要设置让JSP编译servlet使用Jikes，需要修改web.xml文件中jspCompilerPlugin的值：

1. <servlet>
2. <servlet-name>jsp</servlet-name>
3. <servlet-class>
4. org.apache.jasper.servlet.JspServlet
5. </servlet-class>
6. <init-param>
7. <param-name>logVerbosityLevel</param-name>
8. <param-value>WARNING</param-value>
9. </init-param>
10. <init-param>
11. <param-name>jspCompilerPlugin</param-name>
12. <param-value>org.apache.jasper.compiler.JikesJavaCompiler</param-value>
13. </init-param>
14. <init-param>
15. <!-- <param-name>org.apache.catalina.jsp_classpath</param-name> -->
16. <param-name>classpath</param-name>
17. <param-value>
18. /usr/local/jdk1.3.1-linux/jre/lib/rt.jar:
19. /usr/local/lib/java/servletapi/servlet.jar
20. </param-value>
21. </init-param>
22. <load-on-startup>3</load-on-startup>
23. </servlet>

在Tomcat 4.1（或更高版本），JSP的编译由包含在Tomcat里面的Ant程序控制器直接执行。客户开发人员需要在元素中定义一个名字叫”compiler”，并且在value中有一个支持编译的编译器名字，示例如下：

1. <servlet>
2. <servlet-name>jsp</servlet-name>
3. <servlet-class>
4. org.apache.jasper.servlet.JspServlet
5. </servlet-class>
6. <init-param>
7. <param-name>logVerbosityLevel</param-name>
8. <param-value>WARNING</param-value>
9. </init-param>
10. <init-param>
11. <param-name>compiler</param-name>
12. <param-value>jikes</param-value>
13. </init-param>
14. <load-on-startup>3</load-on-startup>
15. </servlet>

Ant可用的编译器 

        由于JSP页面在第一次使用时已经被编译，那么你可能希望在更新新的jsp页面后马上对它进行编译。实际上，这个过程完全可以自动化，因为可以确认的是新的JSP页面在生产服务器和在测试服务器上的运行效果是一样的。
        在Tomcat4的bin目录下有一个名为jspc的脚本。它仅仅是运行翻译阶段，而不是编译阶段，使用它可以在当前目录生成Java源文件。它是调试JSP页面的一种有力的手段。
        可以通过浏览器访问再确认一下编译的结果。这样就确保了文件被转换成servlet，被编译了可直接执行。这样也准确地模仿了真实用户访问JSP页面，可以看到给用户提供的功能。也抓紧这最后一刻修改出现的bug并且修改它。
        Tomcat提供了一种通过请求来编译JSP页面的功能。客户可以在浏览器地址栏中输入http://localhost: 8080/examples/jsp/dates/date.jsp?jsp_precompile=true，这样Tomcat就会编译 data.jsp而不是执行它。此举唾手可得，不失为一种检验页面正确性的捷径。

2.2.4        NIO 配置 
NIO （No-blocking I/O）从JDK 1.4起，NIO API作为一个基于缓冲区，并能提供非阻塞I/O操作的API被引入[LD6] 。 
        TOMCAT可以支持高并发的企业级应用。其中有个很大的原因就是，配置良好的tomcat都会使用APR(Apache Portable Runtime),APR是Apache HTTP Server2.x的核心，它是高度可移植的本地库，它使用高性能的UXIN I/O操作，低性能的java io操作，但是APR对客户开发人员而言可能稍稍有点难度，在很多OS平台上，可能需要重新编译APR。但是从Tomcat6.0以后, 客户开发人员很容易就可以用NIO的技术来提升tomcat的并发处理能力。但是为什么NIO可以提升tomcat的并发处理能力呢，我们先来看一下java 传统io与 java NIO的差别。 
       Java 传统的IO操作都是阻塞式的(blocking I/O), 如果有socket的编程基础，你会接触过堵塞socket和非堵塞socket，堵塞socket就是在accept、read、write等IO操作的时候，如果没有可用符合条件的资源，不马上返回，一直等待直到有资源为止。而非堵塞socket则是在执行select的时候，当没有资源的时候堵塞，当有符合资源的时候，返回一个信号，然后程序就可以执行accept、read、write等操作，一般来说，如果使用堵塞socket，通常我们通常开一个线程accept socket，当读完这次socket请求的时候，开一个单独的线程处理这个socket请求；如果使用非堵塞socket，通常是只有一个线程，一开始是select状，当有信号的时候可以通过多路复用（Multiplexing)技术传递给一个指定的线程池来处理请求，然后原来的线程继续select状态。 最简单的多路复用技术可以通过java管道(Pipe)来实现。换句话说，如果客户端的并发请求很大的时候，客户系统可以使用少于客户端并发请求的线程数来处理这些请求，而这些来不及立即处理的请求会被阻塞在java管道或者队列里面，等待线程池的处理。
        在web服务器上阻塞IO(BIO)与NIO一个比较重要的不同是，客户系统使用BIO的时候往往会为每一个web请求引入多线程，每个web请求一个单独的线程，所以并发量一旦上去了，线程数就上去了，CPU就忙着线程切换，所以BIO不合适高吞吐量、高可伸缩的web服务器；而NIO则是使用单线程(单个CPU)或者只使用少量的多线程(多CPU)来接受Socket，而由线程池来处理堵塞在pipe或者队列里的请求.这样的话，只要OS可以接受TCP的连接，web服务器就可以处理该请求。大大提高了web服务器的可伸缩性。
        客户只需要在server.xml里把 HTTP Connector做如下更改：

1. <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

改为

1. <Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000" redirectPort="8443" />

然后启动服务器，如果出现org.apache.coyote.http11.Http11NioProtocol start的提示信息，表示NIO已经启动。其他的配置请参考官方配置文档。
2.2.5        其它 
        前面我们提到过操作系统通过一些限制手段来防止恶意的服务攻击，同样Tomcat也提供了防止恶意攻击或禁止某些机器访问的设置。 
        Tomcat提供了两个参数供你配置：RemoteHostValve 和RemoteAddrValve。 
        通过配置这两个参数，可以让你过滤来自请求的主机或IP地址，并允许或拒绝哪些主机/IP。与之类似的，在Apache的httpd文件里有对每个目录的允许/拒绝指定。
例如你可以把Admin Web application设置成只允许本地访问，设置如下：

1. <Context path=“/path/to/secret_files”>
2. <Valve className=“org.apache.catalina.valves.RemoteAddrValve” allow=“127.0.0.1”deny=““ />
3. </Context>

如果没有给出允许主机的指定，那么与拒绝主机匹配的主机就会被拒绝，除此之外的都是允许的。与之类似，如果没有给出拒绝主机的指定，那么与允许主机匹配的主机就会被允许，除此之外的都是拒绝的。
3          负载均衡 
        在负载均衡的思路下，多台服务器为对等方式，每台服务器都具有同等的地位，可以单独对外提供服务而无须其他服务器的辅助。通过负载分担技术，将外部发送来的请求按一定规则分配到对称结构中的某一台服务器上，而接收到请求的服务器都独立回应客户机的请求。
        提供服务的一组服务器组成了一个应用服务器集群(cluster)，集群下的对等多机环境可以增加系统的并发处理能力，和单台机器出现故障系统的错误冗余能力；同时实现了负载均衡和系统高可靠性。

四种实现负载均衡的方式： 
第一是通过DNS，但只能实现简单的轮流分配，不能处理故障； 
第二如果是基于MS IIS，Windows 2003 server本身就带了负载均衡服务； 
第三是硬件方式，通过交换机的功能或专门的负载均衡设备可以实现； 
第四种是软件方式，通过一台负载均衡服务器进行，上面安装软件。使用Apache Httpd Server做负载平衡器。 
        客户系统一般采用Apache httpd作为web服务器，即作为Tomcat的前端处理器，根据具体情况而定，有些情况下是不需要Apache httpd作为 web 服务器的，如系统展现没有静态页面那就不需要Apache httpd，那时可以直接使用Tomcat作为web 服务器来使用。使用Apache httpd主要是它在处理静态页面方面的能力比Tomcat强多了。

3.1.1        配置负载均衡器 
        在apache下配置负载均衡器分为三步，注意每次修改httpd.conf和workers2.properties时不要忘了重新启动apache。 
第一步，安装和调试apache 
        负载均衡器jk2模块是apache www 服务的插件，所以配置负载均衡器就得先安装apache。假设客户下载的是windows版本 2.0.43，执行setup.exe并回答一些简单问题就可完成apache的任务。值得注意的是，安装并启动apache后如果apache对http://localhost/ 地址没反应，你得修改apache安装路径下htdocs目录下的index.html.xx文件，比如把index.html.en改成index.html。
第二步，安装jk2 
       把下载到的 mod_jk2-2.0.43.dll改成mod_jk2.dll 放到apache的modules目录下，修改apache的httpd.conf，即在LoadModule foo_module modules/mod_foo.so 行下插入mod_jk2模块的装载信息[LD7] ：

1. # Example:
2. # LoadModule foo_module modules/mod_foo.so
3. #
4. LoadModule jk2_module modules/mod_jk2.dll

第三步，配置jk2

jk2的配置全在一个配置文件中，文件名为workers2.properties，和apache 的httpd.conf放在同一个目录下。以下是这个文件的内容：

1. #++++++++++++++++++++++++++++++++++++
2. # only at beginnin. In production uncomment it out
3. [logger.apache2]
4. level=DEBUG
5. #shm必须配
6. [shm]
7. file=D:\Program Files\Apache Group\Apache2\logs\shm.file
8. size=1048576
9. # 第一个tomcat 的地址
10. # Example socket channel, override port and host.
11. [channel.socket:tomcat1]
12. port=11009
13. host=127.0.0.1
14. # 定义第一个工作者指向第一个tomcat
15. # define the worker
16. [ajp13:tomcat1]
17. channel=channel.socket:tomcat1
18. #第二个tomcat 得地址
19. # Example socket channel, override port and host.
20. [channel.socket:tomcat2]
21. port=12009
22. host=10.1.36.123
23. # 定义第二个工作者指向第二个tomcat
24. # define the worker
25. [ajp13:tomcat2]
26. channel=channel.socket:tomcat2
27. #定义负载均衡器，使其包含两个工作者
28. [lb:lb1]
29. worker=ajp13:tomcat2
30. worker=ajp13:tomcat1
31. #指定负载均衡器完成单一地址映射，使得apache 服务所在的uri全部指向 两个tomcat 上的 root
32. # Uri mapping
33. [uri:/*]
34. group=lb:lb1
35. #++++++++++++++++++++++++++++++++++++++++++

3.1.2        配置tomcat

同属于一个集群下的两个服务实体，要求功能的同一性，所以我们可先安装和配置第一个tomcat，接着拷贝形成第二个tomcat，最后配置第二个tomcat。 
安装tomcat 非常简单，本文就不再描述。我们假设第一个tomcat的安装路径为d:\tomcat1。 
配置第一个tomcat：

tomcat 中的jk2 connector缺省端口为8009，为了在一台机器上运行两个tomcat，修改D:\Tomcat1\conf\jk2.properties，设置jk2 connector的端口为11009，整个文件内容如下：

1. #++++++++++++++
2. channelSocket.port=11009
3. #++++++++++++++

为了让一台机器上运行两个tomcat，修改server.conf的tomcat 停止指令监听端口：

1. <Server port="8005" shutdown="SHUTDOWN" debug="0">

改为

1. <Server port="11005" shutdown="SHUTDOWN" debug="0">

然后打开JK2 AJP connector ，关闭其它connector，下面是JK2 AJP 1.3的样子，这里已把它的端口改为11009：

1. <!-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 -->
2. <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
3. port="11009" minProcessors="5" maxProcessors="75" enableLookups="true"
4. redirectPort="8443" acceptCount="10" debug="0" connectionTimeout="20000"
5. useURIValidationHack="false" protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler" />

接着配置需要集群支持的webapp（比如examples） 的context，添加如下manager：

1. <Manager className="org.apache.catalina.session.InMemoryReplicationManager"
2. protocolStack="UDP(mcast_addr=228.1.2.3;mcast_port=45566;ip_ttl=32):PING(timeout=3000; num_initial_members=6):FD(timeout=5000):VERIFY_SUSPECT(timeout=1500): pbcast.STABLE(desired_avg_gossip=10000):pbcast.NAKACK(gc_lag=10; retransmit_timeout=3000):UNICAST(timeout=5000;min_wait_time=2000): MERGE2:FRAG:pbcast.GMS(join_timeout=5000;join_retry_timeout=2000; shun=false;print_local_addr=false)">
3. </Manager>

注意protocolStack的值必须在一行内写完。 
配置第二个tomcat： 
把已经配好的第一个tomcat复制一份，形成第二个tomcat，假设路径为d:\tomcat2。 
修改D:\Tomcat2\conf\jk2.properties，设置jk2 connector的端口12009，整个文件内容如下：

1. #++++++++++++++
2. channelSocket.port=12009
3. #++++++++++++++

修改server.conf 
有了第一个tomcat的配置我们只需修改server.conf的tomcat 停止指令监听端口： 
<Server port="11005" shutdown="SHUTDOWN" debug="0"> 改为 
<Server port="12005" shutdown="SHUTDOWN" debug="0"> 
然后设置JK2 AJP connector 端口为12009。 
3.1.3        运行测试 
启动apache，tomcat1和tomcat2。

我们先准备两个文件，第一个文件为test.jsp，拷贝到第一个tomcat 的根web应用的目录即d:\tomcat1\webapps\ROOT 下：

1. <html>
2. <body bgcolor="red">
3. <center>
4. <%= request.getSession().getId() %>
5. <h1>Tomcat 1</h1>
6. </body>
7. </html>

第二个文件也为test.jsp，拷贝到第二个tomcat 的根web应用的目录即d:\tomcat2\webapps\ROOT 下：

1. <html>
2. <body bgcolor="blue">
3. <center>
4. <%= request.getSession().getId() %>
5. <h1>Tomcat 2</h1>
6. </body>
7. </html>

从不同的浏览器中多次输入地址http://localhost/test.jsp 会看到不同的颜色，这表明apache中的jk2模块起到了负载均衡的作用。 
4          容量计划 
        容量计划是在生产环境中使用Tomcat不得不提的提高性能的另一个重要的话题。如果你没有对预期的网络流量下的硬件和带宽做考虑的话那么无论你如何做配置修改和测试都无济于事。
        这里先对提及的容量计划作一个简要的定义：容量计划是指评估硬件、操作系统和网络带宽，确定应用服务的服务范围，寻求适合需求和软件特性的软硬件的一项活动。因此这里所说的软件不仅包括Tomcat，也包括与Tomcat结合使用的任何第三方web服务器软件。
        如果在购买软硬件或部署系统前你对容量计划一无所知，不知道现有的软硬件环境能够支撑多少的访问量，甚至更糟直到你已经交付并且在生产环境上部署产品后才意识到配置有问题时再进行变更可能为时已晚。此时只能增加硬件投入，增加硬盘容量甚至购买更好的服务器。如果事先做了容量计划那么就不会搞的如此焦头烂额了。
        我们这里只介绍与Tomcat相关的内容。 
        首先为了确定Tomcat使用机器的容量计划，你应该从一下列表项目种着手研究和计划： 
4.1.1        硬件 
采用什么样的硬件体系？需要多少台计算机？使用一个大型的，还是使用多台小型机？每个计算机上使用几个CPU？使用多少内存？使用什么样的存储设备，I/O的处理速度有什么要求？怎样维护这些计算机？不同的JVM在这些硬件上运行的效果如何（比如IBM AIX系统只能在其设计的硬件系统上运行）？
4.1.2        网络带宽 
带宽的使用极限是多少？web应用程序如何处理过多的请求？ 
4.1.3        服务端操作系统 
采用哪种操作系统作为站点服务器最好？在确定的操作系统上使用哪个JVM最好？例如，JVM在这种系统上是否支持本地多线程，对称多处理？哪种系统可使web服务器更快、更稳定，并且更便宜。是否支持多CPU？
4.1.4        Tomcat容量计划 
以下介绍针对Tomcat做容量计划的步骤： 
1） 量化负载。如果站点已经建立并运行，可以使用工具模仿用户访问，确定资源的需求量。 
2） 针对测试结果或测试过程中进行分析。需要知道那些请求造成了负载过重或者使用过多的资源，并与其它请求做比较，这样就确定了系统的瓶颈所在。例如：如果servlet在查询数据库的步骤上耗用较长的时间，那么就需要考虑使用缓冲池来降低响应时间。
3）确定性能最低标准。例如，你不想让用户花20秒来等待结果页面的返回，也就是说甚至在达到访问量的极限时，用户等待的时间也不能超过20秒种（从点击链接到看到返第一条返回数据）。这个时间中包含了数据库查询时间和文件访问时间。同类产品性能在不同的公司可能有不同的标准，一般最好采取同行中的最低标准或对这个标准做出评估。
4）确定如何合理使用底层资源，并逐一进行测试。底层资源包括CPU、内存、存储器、带宽、操作系统、JVM等等。在各种生产环境上都按顺序进行部署和测试，观察是否符合需求。在测试Tomcat时尽量多采用几种JVM，并且调整JVM使用内存和Tomcat线程池的大小进行测试。同时为了达到资源充分合理稳定地使用的效果，还需针对测试过程中出现的硬件系统瓶颈进行处理确定合理的资源配置。这个过程最为复杂，而且一般由于没有可参考的值所以只能靠理论推断和经验总结。
5） 如果通过第4步的反复测试如果达到了最优的组合，就可以在相同的生产环境上部署产品了。

此外应牢记一定要文档化你的测试过程和结果，因为此后可能还会进行测试，这样就可以拿以前的测试结果作为参考。另外测试过程要反复多次进行，每次的条件可能都不一样，因此只有记录下来才能进行结果比较和最佳条件的选择。

这样客户系统通过测试找到了最好的组合方式，各种资源得到了合理的配置，系统的性能得到了极大的提升。