tomcat服务器优化

一、概述

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

二、调优分类

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

1. 外部环境调优

调整Tomcat运行环境的操作系统参数和运行Tomcat的java虚拟机参数。

(a) JAVA虚拟机性能优化

Tomcat需要依赖Java虚拟机运行。根据客户选用的主机的操作系统选择对应的 JDK的版本。无论哪个厂商的JDK，都建议使用最新的版本。 虚拟机可通过命令行的方式改变虚拟机使用内存的大小。如下表所示有两个参数用来设置虚拟机使用内存的大小。

-Xms<size> ：JVM初始化堆的大小

-Xmx<size> ：JVM堆的最大值

Tomcat默认可以使用的内存较小，在较大型的应用项目中，这点内存是不够的，需要调大。

Windows下，在文件tomcat_home/bin/catalina.bat，Unix下，在文件tomcat_home/bin/catalina.sh的前面，增加如下设置：

JAVA_OPTS=‘-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】

需要把这个两个参数值调大。例如：JAVA_OPTS='-Xms256m -Xmx512m' ，表示初始化内存为256MB，可以使用的最大内存为512MB。

另外需要考虑的是Java提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾可以接受的速度与应用有关，应该通过分析实际的垃圾收集的时间和频率来调整。

如果堆的空间很大，那么完全垃圾收集（FULL GC）就会很慢，但是频度会降低。如果在客户系统中把堆的大小和内存的需要一致，完全收集就很快，但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。对于SUN和HP等虚拟机，推荐将最小堆大小和最大堆大小设置为同一值，因为这样可以避免浪费用于时常调整堆大小所需的 VM 资源。

当然，客户系统如果用到IBM虚拟机，要特别的注意设置-Xms和-Xmx一样大小会耽误垃圾回收的开始直到堆满，这样第一次垃圾回收就会变成非常昂贵的操作。推荐把-Xms设置为应用所需的最小值，这样会产生高效的垃圾回收。

(b) 操作系统性能优化

以客户系统为HP-UX为例。

HP系统中对Tomcat有影响的参数：

    max_thread_proc: 一个进程所能创建的线程的最大数

    nkthread: 在系统上同时允许的核心线程的最大数

如果在输出里看到消息：java.lang.OutOfMemoryError: unable to create new native thread，则说明名为 max_thread_proc 的 Unix 内核设置过小。max_thread_proc 是单个进程中的最大线程数。 它必须大到能够容纳 Java 应用程序中的所有线程以及虚拟机本身中的部分额外线程。

查看核心参数：$ulimit -a

显示输出中的 nofiles 是指用户的进程能同时打开的最大文件句柄数。如果日志中出现”two many open files”的异常，需要重点检查这个参数。coredump 参数是 core 文件最大值的，限制当进程 coredump 时将产生 core文件的大小不能超过这个最大值。如果在日志文件检查时，发现 core文件不完整，需要增大这个参数值。执行 ulimit  -n 命令可以设置 nofiles 参数，执行ulimit -c命令设置 core 文件最大值。

如果是在Windows操作系统上使用Tomcat，那么最好选择服务器版本。因为在非服务器版本上，最终用户授权数或者操作系统本身所能承受的用户数、可用的网络连接数或其它方面的一些方面都是有限制的。并且基于安全性的考虑，必须经常给操作系统打上最新的补丁。

(c) Tomcat与其它Web服务器整合使用

虽然tomcat也可以作web服务器,但其处理静态html的速度比不上apache,且其作为web服务器的功能远不如apache,因此我们想把 apache和tomcat集成起来，将html与jsp的功能部分进行明确分工，让tomcat只处理jsp部分，其它的由apache,IIS等这些 web服务器处理，由此大大节省了tomcat有限的工作线程。

2. 自身调优

本节将说明Tomcat性能调优的技巧和方法，这些技巧和方法与操作系统或Java虚拟机的种类无关。以下方法都是针对Tomcat 性能自身调整的最佳方式。

(a) 禁用DNS查询

当web应用程序要记录客户端的信息时，它也会记录客户端的IP地址或者通过域名服务器查找机器名转换为IP地址。DNS查询需要占用网络，并且包括可能从很多很远的服务器或者不起作用的服务器上去获取对应的IP的过程，这样会消耗一定的时间。为了消除DNS查询对性能的影响我们可以关闭DNS查询，方式是修改server.xml 文件中的enableLookups参数值：

    Tomcat4

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

    Tomcat5

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

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

(b) 调整线程数

另外一个可通过应用程序的连接器（Connector）进行性能控制的参数是创建的处理请求的线程数。Tomcat使用线程池加速响应速度来处理请求。在Java中线程是程序运行时的路径，是在一个程序中与其它控制线程无关的、能够独立运行的代码段。它们共享相同的地址空间。多线程帮助程序员写出CPU最大利用率的高效程序，使空闲时间保持最低，从而接受更多的请求。

Tomcat4中可以通过修改minProcessors和maxProcessors的值来控制线程数。这些值在安装后就已经设定为默认值并且是足够使用的，但是随着站点的扩容而改大这些值。minProcessors服务器启动时创建的处理请求的线程数应该足够处理一个小量的负载。也就是说，如果一天内每秒仅发生5次单击事件，并且每个请求任务处理需要1秒钟，那么预先设置线程数为5就足够了。但在你的站点访问量较大时就需要设置更大的线程数，指定为参数maxProcessors的值。maxProcessors的值也是有上限的，应防止流量不可控制（或者恶意的服务攻击），从而导致超出了虚拟机使用内存的大小。如果要加大并发连接数，应同时加大这两个参数。web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。

在Tomcat5对这些参数进行了调整：

maxThreads ：Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。

acceptCount ：指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。

connnectionTimeout ：网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。

minSpareThreads ：Tomcat初始化时创建的线程数。

maxSpareThreads ：一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。

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

(c) 加速JSP编译速度

当第一次访问一个JSP文件时，它会被转换为Java servlet源码，接着被编译成Java字节码。客户工程师可以控制使用哪个编译器，默认情况下，Tomcat使用命令行javac进行使用的编译器。也可以使用更快的编译器，这里将介绍如何优化它们。

另外一种方法是不要把所有的实现都使用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的值：

    <servlet>

    <servlet-name>jsp</servlet-name>

    <servlet-class>

    org.apache.jasper.servlet.JspServlet

    </servlet-class>

    <init-param>

    <param-name>logVerbosityLevel</param-name>

    <param-value>WARNING</param-value>

    </init-param>

    <init-param>

    <param-name>jspCompilerPlugin</param-name>

    <param-value>org.apache.jasper.compiler.JikesJavaCompiler</param-value>

    </init-param>

    <init-param>

    <!-- <param-name>org.apache.catalina.jsp_classpath</param-name> -->

    <param-name>classpath</param-name>

    <param-value>

    /usr/local/jdk1.3.1-linux/jre/lib/rt.jar:

    /usr/local/lib/java/servletapi/servlet.jar

    </param-value>

    </init-param>

    <load-on-startup>3</load-on-startup>

    </servlet>

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

    <servlet>

    <servlet-name>jsp</servlet-name>

    <servlet-class>

    org.apache.jasper.servlet.JspServlet

    </servlet-class>

    <init-param>

    <param-name>logVerbosityLevel</param-name>

    <param-value>WARNING</param-value>

    </init-param>

    <init-param>

    <param-name>compiler</param-name>

    <param-value>jikes</param-value>

    </init-param>

    <load-on-startup>3</load-on-startup>

    </servlet>

由于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而不是执行它。此举唾手可得，不失为一种检验页面正确性的捷径。

(d) NIO 配置

NIO （No-blocking I/O）从JDK 1.4起，NIO API作为一个基于缓冲区，并能提供非阻塞I/O操作的API被引入 。

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做如下更改，

        <Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443" />
        改为
        <Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
                   connectionTimeout="20000"
                   redirectPort="8443" />

然后启动服务器，如果出现org.apache.coyote.http11.Http11NioProtocol start的提示信息，表示NIO已经启动。其他的配置请参考官方配置文档。

(e) 其他

前面我们提到过操作系统通过一些限制手段来防止恶意的服务攻击，同样Tomcat也提供了防止恶意攻击或禁止某些机器访问的设置。

Tomcat提供了两个参数供你配置：RemoteHostValve 和RemoteAddrValve。 通过配置这两个参数，可以让你过滤来自请求的主机或IP地址，并允许或拒绝哪些主机/IP。与之类似的，在Apache的httpd文件里有对每个目录的允许/拒绝指定。

例如你可以把Admin Web application设置成只允许本地访问，设置如下：

    <Context path=“/path/to/secret_files” >

    <Valve className=“org.apache.catalina.valves.RemoteAddrValve”

    allow=“127.0.0.1”deny=““/>

    </Context>

如果没有给出允许主机的指定，那么与拒绝主机匹配的主机就会被拒绝，除此之外的都是允许的。与之类似，如果没有给出拒绝主机的指定，那么与允许主机匹配的主机就会被允许，除此之外的都是拒绝的。
  转载:http://my.oschina.net/xianggao/blog/87466