一.Tomcat内存优化

1.JAVA_OPTS参数说明

Tomcat内存优化主要是对 tomcat 启动参数优化，我们可以在 tomcat 的启动脚本 catalina.sh 中设置 JAVA_OPTS参数。

服务器参数配置

配置完成后可重启Tomcat ，通过以下命令进行查看配置是否生效：

1.  首先查看Tomcat 进程号：

我们可以看到Tomcat 进程号是 12222 。

1.  查看是否配置生效：

优化 server.xml

Tomcat的主配置文件，该文件中包含很多主要元素，比如Service、Connector、Host等，这些元素都会创建软件"对象"、排序及进程管道中设置的这些元素嵌套方，使我们可以执行过滤、分组等工作。

如果要对该文件做优化，我们需要先了解该文件的结构！

server.xml的结构图：

该文件描述了如何启动Tomcat Server

<Server>
  <Listener />
  <GlobaNamingResources>
  </GlobaNamingResources
  <Service>
    <Connector />
    <Engine>
      <Logger />
      <Realm />
         <host>
           <Logger />
           <Context />
         </host>
    </Engine>
  </Service>
</Server>

针对该文件，我们需要优化的点有如下：

1、 maxThreads 连接数限制

maxThreads 是 Tomcat 所能接受最大连接数。一般设置不要超过8000以上，如果你的网站访问量非常大可能使用运行多个Tomcat实例的方法， 即，在一个服务器上启动多个tomcat然后做负载均衡处理。

这里还需要注意的一点是，tomcat 和 php 不同。php可以按照cpu和内存的情况去配置连接数，上万很正常。而 java 还需要注意 jvm 的参数配置。如果不注意就会因为jvm参数过小而崩溃。

2、多虚拟主机

强烈建议不要使用 Tomcat 的虚拟主机，推荐每个站点使用一个实例。即，可以启动多个 Tomcat，而不是启动一个 Tomcat 里面包含多个虚拟主机。因为 Tomcat是多线程，共享内存，任何一个虚拟主机中的应用崩溃，都会影响到所有应用程序。虽然采用多实例的方式会产生过多的开销，但至少保障了应用程序的隔离和安全。

3、压错传输

tomcat作为一个应用服务器，也是支持 gzip 压缩功能的。我们可以在 server.xml 配置文件中的 Connector 节点中配置如下参数，来实现对指定资源类型进行压缩。

compression="on"             # 打开压缩功能 
compressionMinSize="50"      # 启用压缩的输出内容大小，默认为2KB 
noCompressionUserAgents="gozilla, traviata"      # 对于以下的浏览器，不启用压缩 
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"　# 哪些资源类型需要压缩

提示：

Tomcat 的压缩是在客户端请求服务器对应资源后，从服务器端将资源文件压缩，再输出到客户端，由客户端的浏览器负责解压缩并浏览。相对于普通的浏览过程 HTML、CSS、Javascript和Text，它可以节省40% 左右的流量。更为重要的是，它可以对动态生成的，包括CGI、PHP、JSP、ASP、Servlet,SHTML等输出的网页也能进行压缩，压缩效率也很高。但是， 压缩会增加 Tomcat 的负担，因此最好采用Nginx + Tomcat 或者 Apache + Tomcat 方式，将压缩的任务交由 Nginx/Apache 去做。

一旦启用了这个压缩功能后，我们怎么来测试压缩是否有效呢？首先Tomcat是根据浏览器请求头中的accept-encoding来判断浏览器是否支持 压缩功能，如果这个值包含有gzip，就表明浏览器支持gzip压缩内容的浏览，所以我们可以用httpclient来写一个这样的简单测试程序

import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.methods.GetMethod;
 
public class HttpTester {
 
public static void main(String[] args) throws Exception{
HttpClient http = new HttpClient();
GetMethod get = new GetMethod("http://www.dlog.cn/js/prototype.js");
try{
get.addRequestHeader("accept-encoding", "gzip,deflate");
get.addRequestHeader("user-agent", "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar; Maxthon 2.0)");
int er = http.executeMethod(get);
if(er==200){
System.out.println(get.getResponseContentLength());
String html = get.getResponseBodyAsString();
System.out.println(html);
System.out.println(html.getBytes().length);
}
}finally{
get.releaseConnection();
}
}
 
}

执行这个测试程序，看看它所输出的是什么内容，如果输出的是一些乱码，以及打印内容的长度远小于实际的长度，那么恭喜你，你的配置生效了，你会发现你网站的浏览速度比以前快多了。

4、管理AJP端口

AJP是为 Tomcat 与 HTTP 服务器之间通信而定制的协议，能提供较高的通信速度和效率。如果tomcat前端放的是apache的时候，会使用到AJP这个连接器。由于我们公司前端是由nginx做的反向代理，因此不使用此连接器，因此需要注销掉该连接器。

<!--
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
-->

5、更改关闭 Tomcat 实例的指令

server.xml中定义了可以直接关闭 Tomcat 实例的管理端口。我们通过 telnet 连接上该端口之后，输入 SHUTDOWN （此为默认关闭指令）即可关闭 Tomcat 实例（注意，此时虽然实例关闭了，但是进程还是存在的）。由于默认关闭 Tomcat 的端口和指令都很简单。默认端口为8005，指令为SHUTDOWN 。因此我们需要将关闭指令修改复杂一点。

当然，在新版的 Tomcat 中该端口仅监听在127.0.0.1上，因此大家也不必担心。除非黑客登陆到tomcat本机去执行关闭操作。

修改实例：

<Server port="8005" shutdow n="9SDKJ29jksjf23sjf0LSDF92JKS9DKkjsd">

6、更改 Tomcat 的服务监听端口

一般公司的 Tomcat 都是放在内网的，因此我们针对 Tomcat 服务的监听地址都是内网地址。

修改实例：

<Connector port="8080" address="172.16.100.1" />

7、关闭war自动部署

默认 Tomcat 是开启了对war包的热部署的。为了防止被植入木马等恶意程序，因此我们要关闭自动部署。

修改实例：

<Host name="localhost"  appBase=""
            unpackWARs="false" autoDeploy="false">

二.Tomcat并发优化

1.调整连接器connector的并发处理能力

在Tomcat 配置文件 server.xml 中的 <Connector ... /> 配置中

1.参数说明

maxThreads  客户请求最大线程数

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

maxSpareThreads   Tomcat连接器的最大空闲 socket 线程数

minProcessors：最小空闲连接线程数，用于提高系统处理性能，默认值为 10

maxProcessors：最大连接线程数，即：并发处理的最大请求数，默认值为 75

acceptCount：允许的最大连接数，应大于等于 maxProcessors ，默认值为 100

enableLookups：是否反查域名，取值为： true 或 false 。为了提高处理能力，应设置为 false

redirectPort        在需要基于安全通道的场合，把客户请求转发到基于SSL 的 redirectPort 端口

acceptAccount       监听端口队列最大数，满了之后客户请求会被拒绝（不能小于maxSpareThreads  ）

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

URIEncoding    URL统一编码

其中和最大连接数相关的参数为maxProcessors 和 acceptCount 。如果要加大并发连接数，应同时加大这两个参数。

web server允许的最大连接数还受制于操作系统的内核参数设置，通常 Windows 是 2000 个左右， Linux 是1000 个左右。

2.Tomcat中的配置示例

<Connector port="9027"   
                protocol="HTTP/1.1"  
                maxHttpHeaderSize="8192"  
                maxThreads="1000"  
                minSpareThreads="100"  
                maxSpareThreads="1000"  
                minProcessors="100"  
                maxProcessors="1000"  
                enableLookups="false"  
                URIEncoding="utf-8"  
                acceptCount="1000"  
                redirectPort="8443"  
                disableUploadTimeout="true"/>

3.Tomcat缓存优化

tomcat的maxThreads、acceptCount（最大线程数、最大排队数）

<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
maxThreads="800" acceptCount="1000"/> 

maxThreads：tomcat起动的最大线程数，即同时处理的任务个数，默认值为200

acceptCount：当tomcat起动的线程数达到最大时，接受排队的请求个数，默认值为100

这两个值如何起作用，请看下面三种情况

情况1：接受一个请求，此时tomcat起动的线程数没有到达maxThreads，tomcat会起动一个线程来处理此请求。

情况2：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，tomcat会把此请求放入等待队列，等待空闲线程。

情况3：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，等待队列中的请求个数也达到了acceptCount，此时tomcat会直接拒绝此次请求，返回connection refused

maxThreads如何配置

一般的服务器操作都包括量方面：1计算（主要消耗cpu），2等待（io、数据库等）

第一种极端情况，如果我们的操作是纯粹的计算，那么系统响应时间的主要限制就是cpu的运算能力，此时maxThreads应该尽量设的小，降低同一时间内争抢cpu的线程个数，可以提高计算效率，提高系统的整体处理能力。

第二种极端情况，如果我们的操作纯粹是IO或者数据库，那么响应时间的主要限制就变为等待外部资源，此时maxThreads应该尽量设的大，这样才能提高同时处理请求的个数，从而提高系统整体的处理能力。此情况下因为tomcat同时处理的请求量会比较大，所以需要关注一下tomcat的虚拟机内存设置和linux的open file限制。

我在测试时遇到一个问题，maxThreads我设置的比较大比如3000，当服务的线程数大到一定程度时，一般是2000出头，单次请求的响应时间就会急剧的增加，

百思不得其解这是为什么，四处寻求答案无果，最后我总结的原因可能是cpu在线程切换时消耗的时间随着线程数量的增加越来越大，

cpu把大多数时间都用来在这2000多个线程直接切换上了，当然cpu就没有时间来处理我们的程序了。

以前一直简单的认为多线程=高效率。。其实多线程本身并不能提高cpu效率，线程过多反而会降低cpu效率。

当cpu核心数<线程数时，cpu就需要在多个线程直接来回切换，以保证每个线程都会获得cpu时间，即通常我们说的并发执行。

所以maxThreads的配置绝对不是越大越好。

现实应用中，我们的操作都会包含以上两种类型（计算、等待），所以maxThreads的配置并没有一个最优值，一定要根据具体情况来配置。

最好的做法是：在不断测试的基础上，不断调整、优化，才能得到最合理的配置。

acceptCount的配置，我一般是设置的跟maxThreads一样大，这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。

如果设的较小，可以保证接受的请求较快相应，但是超出的请求可能就直接被拒绝

如果设的较大，可能就会出现大量的请求超时的情况，因为我们系统的处理能力是一定的。

maxThreads 配置要结合 JVM -Xmx 参数调整，也就是要考虑内存开销。

在线上环境中我们是采用了tomcat作为Web服务器，它的处理性能直接关系到用户体验，在平时的工作和学习中，归纳出以下七种调优经验。

1. 服务器资源

    服务器所能提供CPU、内存、硬盘的性能对处理能力有决定性影响。
    (1) 对于高并发情况下会有大量的运算，那么CPU的速度会直接影响到处理速度。
    (2) 内存在大量数据处理的情况下，将会有较大的内存容量需求，可以用-Xmx -Xms -XX:MaxPermSize等参数对内存不同功能块进行划分。我们之前就遇到过内存分配不足，导致虚拟机一直处于full GC，从而导致处理能力严重下降。
    (3) 硬盘主要问题就是读写性能，当大量文件进行读写时，磁盘极容易成为性能瓶颈。最好的办法还是利用下面提到的缓存。

2. 利用缓存和压缩

    对于静态页面最好是能够缓存起来，这样就不必每次从磁盘上读。这里我们采用了Nginx作为缓存服务器，将图片、css、js文件都进行了缓存，有效的减少了后端tomcat的访问。

    另外，为了能加快网络传输速度，开启gzip压缩也是必不可少的。但考虑到tomcat已经需要处理很多东西了，所以把这个压缩的工作就交给前端的Nginx来完成。可以参考之前写的《利用nginx加速web访问》。

    除了文本可以用gzip压缩，其实很多图片也可以用图像处理工具预先进行压缩，找到一个平衡点可以让画质损失很小而文件可以减小很多。曾经我就见过一个图片从300多kb压缩到几十kb，自己几乎看不出来区别。

3. 采用集群

    单个服务器性能总是有限的，最好的办法自然是实现横向扩展，那么组建tomcat集群是有效提升性能的手段。我们还是采用了Nginx来作为请求分流的服务器，后端多个tomcat共享session来协同工作。可以参考之前写的《利用nginx+tomcat+memcached组建web服务器负载均衡》。

4. 优化tomcat参数

    这里以tomcat7的参数配置为例，需要修改conf/server.xml文件，主要是优化连接配置，关闭客户端dns查询。

<Connector port="8080"              
protocol="org.apache.coyote.http11.Http11NioProtocol"             
connectionTimeout="20000" 
redirectPort="8443"              
maxThreads="500" 
minSpareThreads="20"             
acceptCount="100" 
disableUploadTimeout="true"            
enableLookups="false" 
URIEncoding="UTF-8" />

5. 改用APR库

    tomcat默认采用的BIO模型，在几百并发下性能会有很严重的下降。tomcat自带还有NIO的模型，另外也可以调用APR的库来实现操作系统级别控制。

<Connector port="80" protocol="HTTP/1.1"        connectionTimeout="20000"         redirectPort="8443" />

修改为：

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

    NIO模型是内置的，调用很方便，只需要将上面配置文件中protocol修改成org.apache.coyote.http11.Http11NioProtocol，重启即可生效。上面配置我已经改过了，默认的是HTTP/1.1。

    APR则需要安装第三方库，在高并发下会让性能有明显提升。具体安装办法可以参考http://www.cnblogs.com/huangjingzhou/articles/2097241.html。安装完成后重启即可生效。如使用默认protocal就是apr，但最好把将protocol修改成org.apache.coyote.http11.Http11AprProtocol，会更加明确。

    在官方找到一个表格详细说明了这三种方式的区别：

6. 优化网络

    Joel也明确提出了优化网卡驱动可以有效提升性能，这个对于集群环境工作的时候尤为重要。由于我们采用了linux服务器，所以优化内核参数也是一个非常重要的工作。给一个参考的优化参数：

1. 修改/etc/sysctl.cnf文件，在最后追加如下内容：  

net.core.netdev_max_backlog = 32768 
net.core.somaxconn = 32768 
net.core.wmem_default = 8388608 
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
 net.core.wmem_max = 16777216 
net.ipv4.ip_local_port_range = 1024 65000 net.ipv4.route.gc_timeout = 100 
net.ipv4.tcp_fin_timeout = 30 
net.ipv4.tcp_keepalive_time = 1200 
net.ipv4.tcp_timestamps = 0 
net.ipv4.tcp_synack_retries = 2 
net.ipv4.tcp_syn_retries = 2 
net.ipv4.tcp_tw_recycle = 1 
net.ipv4.tcp_tw_reuse = 1 
net.ipv4.tcp_mem = 94500000 915000000 927000000 net.ipv4.tcp_max_orphans = 3276800 net.ipv4.tcp_max_syn_backlog = 65536

2. 保存退出，执行sysctl -p生效

7. 让测试说话

    优化系统最忌讳的就是只调优不测试，有时不适当的优化反而会让性能更低。以上所有的优化方法都要在本地进行性能测试过后再不断调整参数，这样最终才能达到最佳的优化效果。

补充Bio、Nio、Apr模式的测试结果：

    对于这几种模式，我用ab命令模拟1000并发测试10000词，测试结果比较意外，为了确认结果，我每种方式反复测试了10多次，并且在两个服务器上都测试了一遍。结果发现Bio和Nio性能差别非常微弱，难怪默认居然还是Bio。但是采用apr，连接建立的速度会有50%～100%的提升。直接调用操作系统层果然神速啊，这里强烈推荐apr方式！

Tomcat的四种基于HTTP协议的Connector性能比较

1. JVM

服务器上不要安装JDK，请使用 Server JRE. 服务器上根本不需要编译器，代码应该在Release服务器上完成编译打包工作。

理由：一旦服务器被控制，可以防止在其服务器上编译其他恶意代码并植入到你的程序中。

3. Tomcat 安全配置

当Tomcat完成安装后你首先要做的事情如下：

首次安装完成后立即删除webapps下面的所有代码

rm -rf /srv/apache-tomcat/webapps/*

注释或删除 tomcat-users.xml 所有用户权限，看上去如下：

# cat conf/tomcat-users.xml
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
</tomcat-users>

隐藏Tomcat版本信息

vim $CATALINA_HOME/conf/server.xml

    <Connector port="80" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443"
				maxThreads="8192"
				minSpareThreads="64"
				maxSpareThreads="128"
				acceptCount="128"
				enableLookups="false"
                server="Neo App Srv 1.0"/>



# curl -I http://localhost:8080/
HTTP/1.1 400 Bad Request
Transfer-Encoding: chunked
Date: Thu, 20 Oct 2011 09:51:55 GMT
Connection: close
Server: Neo App Srv 1.0

服务器信息已经被改为 Server: Neo App Srv 1.0

不要使用root用户启动tomcat，Java程序与C程序不同。nginx,httpd 使用root用户启动守护80端口，子进程/线程会通过setuid(),setgid()两个函数切换到普通用户。即父进程所有者是root用户，子进程与多线程所有者是一个非root用户，这个用户没有shell，无法通过ssh与控制台登陆系统，Java 的JVM 是与系统无关的，是建立在OS之上的，你使用什么用户启动Tomcat，那麽Tomcat 就会继承该所有者的权限。

这造成了一个问题，Linux系统小于1024的端口只有root可以使用，这也是为什么Tomcat默认端口是8080。如果你想使用80端口只能使用root启动Tomcat。这有带来了很多安全问题。

解决方案是创建一个不同用户，如：

groupadd -g 80 daemon
adduser -o --home /daemon --shell /sbin/nologin --uid 80 --gid 80 -c "Web Server" daemon

注意 /sbin/nologin , 意味着该用户不能登录，同时我也没有给它指定密码，这个用户只能用于启动tomcat

chown daemon:daemon -R /srv/*
su - daemon -c "/srv/apache-tomcat/bin/startup.sh"

接下来解决80端口问题, 思路就是80去调用8080，或者映射端口。

下面是影射方案,80 跳转 8080

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

取消跳转
iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

查看规则
iptables -t nat -L

另一个就是从80请求去调用8080的方案

这个方案可以在 Tomcat 前段增加反向代理，例如：Nginx,Apache,Squid,Varnish或者F5， Array这类设备等等

关闭war自动部署 unpackWARs="false" autoDeploy="false"。防止被植入木马等恶意程序

应用程序部署与tomcat启动,不能使用同一个用户。

我的tomcat 安装在 /srv目录下，Tomcat启动用户为daemon; 应用程序放在/www目录下www所有者是www用户。这样的目的是一旦tomcat被植入web shell程序，它将不能创建或编辑/www目录下面的任何内容。

adduser --home /www -c "Web Application" www

修改 Cookie 变量 JSESSIONID， 这个cookie 是用于维持Session关系。建议你改为PHPSESSID。