Tomcat优化详细教程

Tomcat优化详细教程

转载 2017年07月11日 17:22:38

• 标签：
• linux tomcat /
• tomcat优化

• 3048

 Tomcat是咱们常用的 servlet容器之一，甚至不少线上产品都使用 Tomcat充当服务器。并且优化后的Tomcat性能提高显著，本文从如下几方面进行分析优化。

 

        1、内存优化

        默认状况下Tomcat的相关内存配置较低，这对于一些大型项目显然是不够用的，这些项目运行就已经耗费了大部份内存空间，况且大规模访问的状况。即便是本文中的这个只有一个页面的超小项目，在并发达到必定程度后也会抛出如下相似异常：

Java代码  

1. 严重: Exception invoking periodic operation: java.lang.OutOfMemoryError: Java heap space  
2.   
3. 严重: Error processing request java.lang.OutOfMemoryError: GC overhead limit exceeded  

        说明Tomcat已经无力支持访问处理，内部GC也已经“无能无力”。因此通常状况下咱们须要从新配置Tomcat的相关内存大小。

        1.修改内存等 JVM相关配置

        Linux下修改TOMCAT_HOME/bin/catalina.sh，在其中加入，能够放在CLASSPATH=下面：

Java代码  

1. JAVA_OPTS="-server -XX:PermSize=512M -XX:MaxPermSize=1024m -Xms2048m -Xmx2048m"  

        windows下修改TOMCAT_HOME/bin/catalina.bat，在其中加入，能够放在set CLASSPATH=下面：

Java代码  

1. set JAVA_OPTS=-server -XX:PermSize=512M -XX:MaxPermSize=1024m -Xms2048m -Xmx2048m  

        这些参数在咱们学习JVM部分文章时已经都认识过了，不过这里仍是简单介绍下：

        -server：启用 JDK的 server 版本；

        -Xms：Java虚拟机初始化时堆的最小内存，通常与 Xmx配置为相同值，这样的好处是GC没必要再为扩展内存空间而消耗性能；

        -Xmx：Java虚拟机可以使用堆的最大内存；

        -XX:PermSize：Java虚拟机永久代大小；

        -XX:MaxPermSize：Java虚拟机永久代大小最大值；

        除了这些参数外您还能够根据具体须要配置其余参数，参数的配置能够参考JVM参数的配置

        2.验证

        设置成功后咱们能够利用JDK自带的工具进行验证，这些工具都在JAVA_HOME/bin目录下：

        1）jps：用来显示本地的java进程，以及进程号，进程启动的路径等。

        2）jmap：观察运行中的JVM 物理内存的占用状况，包括Heap size , Perm size 下载地址 等。

        进入命令行模式后，进入JAVA_HOME/bin目录下，而后输入jps命令：

Java代码  

1. jps  
2. #显示如下结果  
3. 2340 Bootstrap  
4. 6696 Jps  

        其中 Bootstrap进程就是咱们启动了的 Tomcat，其进程号为2340.

        而后咱们利用 jmap工具查看其内存相关配置：

Java代码  

1. jmap -heap 2340  
2. #显示如下结果  
3. Attaching to process ID 2340, please wait...  
4. Debugger attached successfully.  
5. Server compiler detected.  
6. JVM version is 24.65-b04  
7.   
8. using thread-local object allocation.  
9. Parallel GC with 4 thread(s)  
10.   
11. Heap Configuration:  
12.    MinHeapFreeRatio = 0  
13.    MaxHeapFreeRatio = 100  
14.    MaxHeapSize      = 2147483648 (2048.0MB)    //最大堆内存  
15.    NewSize          = 1310720 (1.25MB)  
16.    MaxNewSize       = 17592186044415 MB  
17.    OldSize          = 5439488 (5.1875MB)  
18.    NewRatio         = 2  
19.    SurvivorRatio    = 8  
20.    PermSize         = 536870912 (512.0MB)      //永久代初始大小  
21.    MaxPermSize      = 1073741824 (1024.0MB)    //永久代最大大小  
22.    G1HeapRegionSize = 0 (0.0MB)  
23. Heap Usage:  
24. PS Young Generation  
25. Eden Space:  
26.    capacity = 537919488 (513.0MB)  
27.    used     = 247606720 (236.13616943359375MB)  
28.    free     = 290312768 (276.86383056640625MB)  
29.    46.03044238471613% used  
30. From Space:  
31.    capacity = 89128960 (85.0MB)  
32.    used     = 0 (0.0MB)  
33.    free     = 89128960 (85.0MB)  
34.    0.0% used  
35. To Space:  
36.    capacity = 89128960 (85.0MB)  
37.    used     = 0 (0.0MB)  
38.    free     = 89128960 (85.0MB)  
39.    0.0% used  
40. PS Old Generation  
41.    capacity = 1431830528 (1365.5MB)  
42.    used     = 0 (0.0MB)  
43.    free     = 1431830528 (1365.5MB)  
44.    0.0% used  
45. PS Perm Generation  
46.    capacity = 536870912 (512.0MB)  
47.    used     = 20770360 (19.80815887451172MB)  
48.    free     = 516100552 (492.1918411254883MB)  
49.    3.86878103017807% used  
50.   
51. 12005 interned Strings occupying 1039352 bytes.  

        从结果就能够看出咱们的配置已经成功了。

 

        2、配置优化

        咱们知道TOMCAT_HOME/conf/server.xml能够配置端口，虚拟路径等等 Tomcat相关主要配置。

        1.Connector 优化

        Connector是链接器，负责接收客户的请求，以及向客户端回送响应的消息。因此 Connector的优化是重要部分。默认状况下 Tomcat只支持200线程访问，超过这个数量的链接将被等待甚至超时放弃，因此咱们须要提升这方面的处理能力。

        修改这部分配置须要修改TOMCAT_HOME/conf/server.xml，打开server.xml找到Connector 标签项，默认配置以下：

Xml代码  

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

        其中port表明服务接口；protocol表明协议类型；connectionTimeout表明链接超时时间，单位为毫秒；redirectPort表明安全通讯（https）转发端口，通常配置成443。

        能够看到除了这几个基本配置外并没有特殊功能，因此咱们须要对 Connector 进行扩展。

        其中Connector 支持参数属性能够参考Tomcat官方网站（https://tomcat.apache.org/tomcat-8.0-doc/config/http.html），很是多，因此本文就只介绍些经常使用的。

        咱们将 Connector 配置修改成以下：

Java代码  

1. <Connector port="8080"   
2.           protocol="HTTP/1.1"   
3.           maxThreads="1000"   
4.           minSpareThreads="100"   
5.           acceptCount="1000"  
6.           maxConnections="1000"  
7.           connectionTimeout="20000"   
8.           maxHttpHeaderSize="8192"  
9.           tcpNoDelay="true"  
10.           compression="on"  
11.           compressionMinSize="2048"  
12.           disableUploadTimeout="true"  
13.           redirectPort="8443"  
14.       enableLookups="false"  
15.           URIEncoding="UTF-8" />  

 

        1）port：表明Tomcat监听端口，也就是网站的访问端口，默认为8080，能够根据须要改为其余。

        2）protocol：协议类型，可选类型有四种，分别为BIO（阻塞型IO），NIO，NIO2和APR。

        （1）BIO：BIO(Blocking I/O)，顾名思义，即阻塞式I/O操做，表示Tomcat使用的是传统的Java I/O操做(即java.io包及其子包)。Tomcat在默认状况下，是以bio模式运行的。遗憾的是，就通常而言，bio模式是三种运行模式中性能最低的一种。BIO配置采用默认便可。

        （2）NIO：NIO(New I/O)，是Java SE 1.4及后续版本提供的一种新的I/O操做方式(即java.nio包及其子包)。Java nio是一个基于缓冲区、并能提供非阻塞I/O操做的java API，所以nio也被当作是non-blocking I/O的缩写。它拥有比传统I/O操做(bio)更好的并发运行性能。要让Tomcat以nio模式来运行也比较简单，咱们只须要protocol类型修改成：

Java代码  

1. //NIO  
2. protocol="org.apache.coyote.http11.Http11NioProtocol"  
3. //NIO2  
4. protocol="org.apache.coyote.http11.Http11Nio2Protocol"  

        便可。

        （3）APR：APR(Apache Portable Runtime/Apache可移植运行时)，是Apache HTTP服务器的支持库。你能够简单地理解为:Tomcat将以JNI的形式调用 Apache HTTP服务器的核心动态连接库来处理文件读取或网络传输操做，从而大大地提升 Tomcat对静态文件的处理性能。 

        与配置 NIO运行模式同样，也须要将对应的 Connector节点的 protocol属性值改成：

Java代码  

1. protocol="org.apache.coyote.http11.Http11AprProtocol"  

        相关APR介绍及配置会在下面专门讲。

        3）maxThreads：由该链接器建立的处理请求线程的最大数目，也就是能够处理的同时请求的最大数目。若是未配置默认值为200。若是一个执行器与此链接器关联，则忽略此属性，由于该属性将被忽略，因此该链接器将使用执行器而不是一个内部线程池来执行任务。

        maxThreads是一个重要的配置属性，maxThreads配置的合理直接影响了Tomcat的相关性能，因此这里咱们重点讨论下。

        maxThreads并非配置的越大越好，事实上你即便配置成999999也是没有用的，由于这个最大值是受操做系统及相关硬件所制约的，而且最大值并不必定是最优值，因此咱们追寻的应该是最优值而不是最大值。

        QPS（Query Per Second）：每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。咱们经常使用 QPS值来衡量一个服务器的性能。

        QPS = 并发数 / 平均响应时间

        或者

        并发数 = QPS * 平均响应时间

        一个系统吞吐量一般由QPS、并发数两个因素决定，每套系统的这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，若是压力继续增大，系统的吞吐量反而会降低，缘由是系统超负荷工做，上下文切换、内存等等其它消耗致使系统性能降低。所谓吞吐量这里能够理解为每秒能处理请求的次数。

        因此选择一个合理的 maxThreads值，其实并非那么容易的事。由于过多的线程只会形成，更多的内存开销，更多的CPU开销，可是对提高QPS确毫无帮助；找到最佳线程数后经过简单的设置，可让web系统更加稳定，获得最高，最稳定的QPS输出。

        咱们能够经过如下几种方式来获取 maxThreads的最佳值：

        （1）经过线上系统不断使用和用户的不断增加来进行性能测试，观察QPS，响应时间，这种方式会在爆发式增加时系统崩溃，如双12等。

        （2）根据公式计算，服务器端最佳线程数量=((线程等待时间+线程cpu时间)/线程cpu时间) * cpu数量，这种方式有时会被误导，由于某些系统处理环节可能会耗时比较长，从而影响公式的结果。

        （3）单、多用户压力测试，查看CPU的消耗，而后直接乘以百分比，再进行压测，通常这个值的附近应该就是最佳线程数量，这种方式理想场景比较适用，实际状况会比这个复杂的多。

        （4）根据系统的自身状况调整，如硬件限制，系统限制，程序处理能力限制等。

        （5）按期修改成不一样的 maxThreads值，看服务器响应结果及用户反应。

        QPS和线程数的关系

        （1）在最佳线程数量以前，QPS和线程是互相递增的关系，线程数量到了最佳线程以后，QPS持平，不在上升，甚至略有降低，同时相应时间持续上升。

        （2）同一个系统而言，支持的线程数越多（最佳线程数越多而不是配置的线程数越多），QPS越高。

        QPS和响应时间的关系

        （1）对于通常的web系统，响应时间通常有CPU执行时间+IO等待时间组成。

        （2）CPU的执行时间减小，对QPS有实质的提高，IO时间的减小，对QPS提高不明显。若是要想明显提高QPS，优化系统的时候要着重优化CPU消耗大户。

        因此想要找出 maxThreads的最优值可并不容易，没有最好只有更好，更好的值只能经过时间来显现，若是你不想考虑那么多，通常状况下设置成1000便可。

        4）minSpareThreads：线程的最小运行数目，这些始终保持运行。若是未指定，默认值为10。

        5）acceptCount：当全部可能的请求处理线程都在使用时传入链接请求的最大队列长度。若是未指定，默认值为100。通常是设置的跟 maxThreads同样或一半，此值设置的过大会致使排队的请求超时而未被处理。因此这个值应该是主要根据应用的访问峰值与平均值来权衡配置。

        6）maxConnections：在任何给定的时间内，服务器将接受和处理的最大链接数。当这个数字已经达到时，服务器将接受但不处理，等待进一步链接。NIO与NIO2的默认值为10000，APR默认值为8192。

        7）connectionTimeout：当请求已经被接受，但未被处理，也就是等待中的超时时间。单位为毫秒，默认值为60000。一般状况下设置为30000。

        8）maxHttpHeaderSize：请求和响应的HTTP头的最大大小，以字节为单位指定。若是没有指定，这个属性被设置为8192（8 KB）。

        9）tcpNoDelay：若是为true，服务器socket会设置TCP_NO_DELAY选项，在大多数状况下能够提升性能。缺省状况下设为true。

        10）compression：是否启用gzip压缩，默认为关闭状态。这个参数的可接受值为“off”（不使用压缩），“on”（压缩文本数据），“force”（在全部的状况下强制压缩）。

        11）compressionMinSize：若是compression="on"，则启用此项。被压缩前数据的最小值，也就是超过这个值后才被压缩。若是没有指定，这个属性默认为“2048”（2K），单位为byte。

        12）disableUploadTimeout：这个标志容许servlet Container在一个servlet执行的时候，使用一个不一样的，更长的链接超时。最终的结果是给servlet更长的时间以便完成其执行，或者在数据上载的时候更长的超时时间。若是没有指定，设为false。

        13）enableLookups：关闭DNS反向查询。

        14）URIEncoding：URL编码字符集。

        Connector 还有不少其余参数，能够参考Tomcat官网，这里只介绍与性能相关的部分。

        2.BIO、NIO、APR

        经过配置 protocol的类型可使用不一样的 Connector处理请求。

Java代码  

1. //BIO  
2. protocol="HTTP/1.1"  
3. //NIO  
4. protocol="org.apache.coyote.http11.Http11NioProtocol"  
5. //NIO2  
6. protocol="org.apache.coyote.http11.Http11Nio2Protocol"  
7. //APR  
8. protocol="org.apache.coyote.http11.Http11AprProtocol"  

        如下是几种类型 Connector的参数对比：

        并非说 BIO的性能就必定不如 NIO，这几种类型 Connector之间并无明显的性能区别，它们之间实现流程和原理不一样，因此它们的选择是须要根据应用的类型来决定的。

        BIO更适合处理简单流程，如程序处理较快能够当即返回结果。简单项目及应用能够采用BIO。

        NIO更适合后台须要耗时完成请求的操做，如程序接到了请求后须要比较耗时的处理这已请求，因此没法当即返回结果，这样若是采用BIO就会占用一个链接，而使用NIO后就能够将此链接转让给其余请求，直至程序处理完成返回为止。

        APR能够大大提高Tomcat对静态文件的处理性能，同时若是你使用了HTTPS方式传输的话，也能够提高SSL的处理性能。

        本文的最后会对几种 Connector进行对比测试。

        3.线程池

        Executor表明了一个线程池，能够在Tomcat组件之间共享。使用线程池的好处在于减小了建立销毁线程的相关消耗，并且能够提升线程的使用效率。

        要想使用线程池，首先须要在 Service标签中配置 Executor，以下：

Java代码  

1. <Service name="Catalina">  
2.   
3.   <Executor name="tomcatThreadPool"   
4.          namePrefix="catalina-exec-"   
5.          maxThreads="1000"   
6.          minSpareThreads="100"  
7.          maxIdleTime="60000"  
8.          maxQueueSize="Integer.MAX_VALUE"  
9.          prestartminSpareThreads="false"  
10.          threadPriority="5"  
11.          className="org.apache.catalina.core.StandardThreadExecutor"/>  
12.   ....  

        其中，

        name：线程池名称，用于 Connector中指定。

        namePrefix：所建立的每一个线程的名称前缀，一个单独的线程名称为 namePrefix+threadNumber。

        maxThreads：池中最大线程数。

        minSpareThreads：活跃线程数，也就是核心池线程数，这些线程不会被销毁，会一直存在。

        maxIdleTime：线程空闲时间，超过该时间后，空闲线程会被销毁，默认值为6000（1分钟），单位毫秒。

        maxQueueSize：在被执行前最大线程排队数目，默认为Int的最大值，也就是广义的无限。除非特殊状况，这个值不须要更改，不然会有请求不会被处理的状况发生。

        prestartminSpareThreads：启动线程池时是否启动 minSpareThreads部分线程。默认值为false，即不启动。

        threadPriority：线程池中线程优先级，默认值为5，值从1到10。

        className：线程池实现类，未指定状况下，默认实现类为org.apache.catalina.core.StandardThreadExecutor。若是想使用自定义线程池首先须要实现 org.apache.catalina.Executor接口。

        线程池配置完成后须要在 Connector中指定：

Java代码  

1. <Connector executor="tomcatThreadPool"  
2. ...  

        4.Listener

        另外一个影响Tomcat 性能的因素是内存泄露。Server标签中能够配置多个Listener，其中 JreMemoryLeakPreventionListener是用来预防JRE内存泄漏。此Listener只需在Server标签中配置便可，默认状况下无需配置，已经添加在 Server中。

Java代码  

1. <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />  

 

        3、组件优化

        1.APR

        以前一直都在说APR，那么APR到底能给咱们带来什么？这节就开始学习APR相关知识。

        APR(Apache Portable Runtime)是一个高可移植库，它是Apache HTTP Server 2.x的核心。APR有不少用途，包括访问高级 IO功能(例如sendfile,epoll和OpenSSL)，OS级别功能(随机数生成，系统状态等等)，本地进程管理(共享内存，NT管道和UNIX sockets)。这些功能可使Tomcat做为一个一般的前台WEB服务器，能更好地和其它本地web技术集成，整体上让Java更有效率做为一个高性能web服务器平台而不是简单做为后台容器。

        APR的目的如其名称同样，主要为上层的应用程序提供一个能够跨越多操做系统平台使用的底层支持接口库。在早期的Apache版本中，应用程序自己必须可以处理各类具体操做系统平台的细节，并针对不一样的平台调用不一样的处理函数。随着Apache的进一步开发，Apache组织决定将这些通用的函数独立出来并发展成为一个新的项目。这样，APR的开发就从Apache中独立出来，Apache仅仅是使用APR而已。目前APR主要仍是由Apache使用，不过因为APR的较好的移植性，所以一些须要进行移植的C程序也开始使用APR。

        APR使得平台细节的处理进行下移。对于应用程序而言，它们根本就不须要考虑具体的平台，无论是Unix、linux仍是Window，应用程序执行的接口基本都是统一一致的。所以对于APR而言，可移植性和统一的上层接口是其考虑的一个重点。而APR最先的目的并非如此，它最先只是但愿将Apache中用到的全部代码合并为一个通用的代码库，然而这不是一个正确的策略，所以后来APR改变了其目标。有的时候使用公共代码并非一件好事，好比如何将一个请求映射到线程或者进程是平台相关的，所以仅仅一个公共的代码库并不能完成这种区分。APR的目标则是但愿安全合并全部的可以合并的代码而不须要牺牲性能。

       （1）下载

        APR没有二进制包能够下载，因此只能下载源代码版，下载后须要构建，须要下载的文件有：apr-1.5.2.tar.gz、apr-iconv-1.2.1.tar.gz、apr-util-1.5.4.tar.gz（Linux版为例）这三个。

        APR的官网为：http://apr.apache.org/

       （2）安装

        windows下构建源代码比较麻烦，须要Visual Studio支持。

        Linux下构建就相对简单和熟悉了，只须要执行常规构建命令便可：

Java代码  

1. ./configure --prefix=/usr/local/apr  
2. make  
3. make install  

        安装成功后，APR会默认安装在 /usr/local/apr目录下，也能够指定安装目录。

        apr-iconv安装时须要指定apr的安装位置：

Java代码  

1. ./configure --prefix=/usr/local/apr-iconv --with-apr=/usr/local/apr   
2. make   
3. make install  

        apr-util安装时须要指定apr的安装位置：

Java代码  

1. ./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr --with-apr-iconv=/usr/local/apr-iconv/bin/apriconv   
2. make   
3. make install   

        安装完成后目录结构：

        安装完成后实际上是没法直接使用APR的，想使用APR还须要安装Tomcat Native，不然Tomcat启动时会报如下错误：

Java代码  

1. 16-May-2016 02:52:42.992 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/local/apr/lib:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib  

        2.Tomcat Native

        Tomcat Native是 Tomcat可选组件，它可让 Tomcat使用 Apache 的 APR包来处理包括文件和网络IO操做，从而提高性能及兼容性。

        1）下载

        Tomcat Native能够选择Windows与Linux版本下载。

        Tomcat Native下载地址为：http://tomcat.apache.org/download-native.cgi

        2）安装

      （1）Linux/Unix下

        安装Tomcat Native前须要安装如下组件：

        • APR library（咱们已安装）

        • OpenSSL libraries

        • Java SE Development Kit (JDK)（也已安装）

        OpenSSL libraries安装经过如下命令：

Java代码  

1. yum install apr-devel openssl-devel  

        安装成功后就能够安装Tomcat Native了，运行如下命令下载地址：

Java代码  

1. ./configure --with-apr=/usr/local/apr/bin/apr-1-config \  
2.             --with-java-home=/usr/java/jdk1.7.0_79 \  
3.             --with-ssl=yes \  
4.             --prefix=/usr/local/tomcat  

        注意，--prefix指向的是 Tomcat目录。

        注意，下载后的 Tomcat Native解压后目录结构以下：

        安装时须要进入native目录。
        安装过程当中还有可能产生依赖包版本不兼容的问题（通常为openssl版本太低），这时须要卸载旧的依赖，并安装最新版本

        当安装完成后出现如下相似输出时，说明安装已经成功：

Java代码  

1. ----------------------------------------------------------------------  
2. Libraries have been installed in:  
3.    /usr/local/tomcat/lib  
4.   
5. If you ever happen to want to link against installed libraries  
6. in a given directory, LIBDIR, you must either use libtool, and  
7. specify the full pathname of the library, or use the `-LLIBDIR'  
8. flag during linking and do at least one of the following:  
9.    - add LIBDIR to the `LD_LIBRARY_PATH' environment variable  
10.      during execution  
11.    - add LIBDIR to the `LD_RUN_PATH' environment variable  
12.      during linking  
13.    - use the `-Wl,-rpath -Wl,LIBDIR' linker flag  
14.    - have your system administrator add LIBDIR to `/etc/ld.so.conf'  
15.   
16. See any operating system documentation about shared libraries for  
17. more information, such as the ld(1) and ld.so(8) manual pages.  
18. ----------------------------------------------------------------------  

      （2）Windows下

        Windows下安装就异常简单了，只须要把bin目录下文件复制到tomcat/bin下便可，若是为64位，则复制x64中文件下载地址。

        3）使用

       （1）环境变量配置

        使用前须要配置环境变量：

Java代码  

1. vi /etc/profile  

        打开配置文件后，添加如下内容：

Java代码  

1. export LD_LIBRARY_PATH=/usr/local/apr/lib  

        退出保存，而后执行：

Java代码  

1. source /etc/profile  

       （2）修改Tomcat配置文件

        打开conf/server.xml文件，修改Connector 标志的protocol属性：

Java代码  

1. protocol="org.apache.coyote.http11.Http11AprProtocol"  

        而后添加Listener：

Java代码  

1. <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />  

        保存配置文件后，启动Tomcat，从日志中看到如下输出时，说明所有功能都已配置成功：

Java代码  

1. 16-May-2016 04:28:54.734 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR based Apache Tomcat Native library 1.1.34 using APR version 1.5.2.  
2. 16-May-2016 04:28:54.734 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true].  
3. 16-May-2016 04:28:54.739 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized (OpenSSL 1.0.2h  3 May 2016)  

        至此，APR与 Native都已安装完成，可使用，对于 APR与 Native还有不少知识要学习，但不是本文的重点，因此之后有机会还会深刻学习。

 

        4、性能测试

        Tomcat优化部分咱们已经完成，接下来就须要比较一下优化前与优化后的性能对比。

        1.Jmeter

        Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件作压力测试，它最初被设计用于Web应用测试，但后来扩展到其余测试领域。 它能够用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器， 等等。JMeter 能够用于对服务器、网络或对象模拟巨大的负载，来自不一样压力类别下测试它们的强度和分析总体性能。另外，JMeter可以对应用程序作功能/回归测试，经过建立带有断言的脚原本验证你的程序返回了你指望的结果。为了最大限度的灵活性，JMeter容许使用正则表达式建立断言。

        Apache jmeter 能够用于对静态的和动态的资源（文件，Servlet，Perl脚本，java 对象，数据库和查询，FTP服务器等等）的性能进行测试。它能够用于对服务器、网络或对象模拟繁重的负载来测试它们的强度或分析不一样压力类型下的总体性能。你可使用它作性能的图形分析或在大并发负载测试你的服务器/脚本/对象。

        Jmeter官网：http://jmeter.apache.org/

        1）JMeter的做用

       （1）可以对HTTP和FTP服务器进行压力和性能测试， 也能够对任何数据库进行一样的测试（经过JDBC），Jmeter支持如下服务器协议类型测试：

        • Web - HTTP, HTTPS

        • SOAP / REST

        • FTP

        • Database via JDBC

        • LDAP

        • Message-oriented middleware (MOM) via JMS

        • Mail - SMTP(S), POP3(S) and IMAP(S)

        • MongoDB (NoSQL)

        • Native commands or shell scripts

        • TCP

      （2）彻底的可移植性和100% 纯java。

      （3）彻底 Swing 和轻量组件支持（预编译的JAR使用 javax.swing.*)包。

      （4）彻底多线程 框架容许经过多个线程并发取样和 经过单独的线程组对不一样的功能同时取样。

      （5）精心的GUI设计容许快速操做和更精确的计时。

      （6）缓存和离线分析/回放测试结果。

        2）JMeter下载地址特性

      （1）可连接的取样器容许无限制的测试能力。

      （2）各类负载统计表和可连接的计时器可供选择。

      （3）数据分析和可视化插件提供了很好的可扩展性以及个性化。

      （4）具备提供动态输入到测试的功能（包括JavaScript）。

      （5）支持脚本编程的取样器（在1.9.2及以上版本支持BeanShell）。

        在设计阶段，JMeter可以充当HTTP PROXY（代理）来记录IE/NETSCAPE的HTTP请求，也能够记录apache等WebServer的log文件来重现HTTP流量。当这些HTTP客户端请求被记录之后，测试运行时能够方便的设置重复次数和并发度（线程数）来产生巨大的流量。JMeter还提供可视化组件以及报表工具把量服务器在不一样压力下的性能展示出来。

        相比其余HTTP测试工具,JMeter最主要的特色在于扩展性强。JMeter可以自动扫描其lib/ext子目录下.jar文件中的插件，而且将其装载到内存，让用户经过不一样的菜单调用。

        3）Jmeter使用

        使用Jmeter很是简单，windows下进入bin目录直接双击jmeter.bat文件便可，Linux下相似，须要运行jmeter.sh文件，Jmeter运行后显示如下界面：

         Jmeter使用起来比较简单，附件是一个简单的配置，直接导入便可使用。

        2.测试条件

        Tomcat版本：8.0.33

        测试项目：新建立一个web项目也不用实现任何代码，只须要部署便可以使用，只有一个index.jsp文件。

        JDK版本：jdk1.7.0.67

        请求方式：POST

        循环次数：100，1000

        线程数：10,100,1000

        总次数：总次数 = 线程数 * 循环次数

        CPU：英特尔 第二代酷睿 i5-2450M（双核）

        内存：8GB

        附件时Jmeter的配置文件，能够直接导入使用。

        3.测试结果

        从部分结果来看优化过的Tomcat会比默认性能及并发处理能力上有提升，但至于参数的配置须要结合硬件及操做系统来不断调整，因此并不会有一个万能的参数来使用，须要各位不断的测试不断更改。

        如下是一个简单的测试结果，循环100次，线程数分别为10,100,1000：

        各位估计已经发现了相同的应用下并不必定某种protocol就必定性能出色，由于Tomcat中的这个测试项目只有一个index.jsp页面，在较少线程数访问状况下BIO反应最快，而当线程数达到1000时NIO2性能最出色，而APR中规中矩，虽然这种测试的局限性很大，但也能够反映出：想要找出适合的配置及最佳性能须要结合实际，不断的测试与改进，最终才能达到一个相对稳定的性能，虽然此时的性能未必是最佳的，但倒是能应对绝大多数状况的。

        总结：Tomcat相关优化也只是一个入门介绍，每一种技术之中仍是有不少很深奥的知识要去学习，只有不断的去学习才能不断的提升。