Tomcat12——tomcat性能

1. tomcat性能测试

        对于系统性能，用户最直观的感受就是系统的加载时间和操作时间，即用户执行某项操作的耗时。从更专业的角度上讲，性能可以从两个指标量化：

1）响应时间：为执行某个操作的耗时，大多数情况下，我们需要针对同一个操作测试多次，以获取操作的平均响应时间。

2）吞吐量：即在给定的时间内，系统支持的事务数量，计算单位为TPS。

通常情况下，我们需要借助一些自动化工具来进行性能测试，因为手动模拟大量用户的并发访问几乎是不可行的，而且现在市面上也有很多的性能测试工具可以使用，如：ApacheBench、ApacheJMeter、WCAT、WebPolygraph、LoadRunnner。

1.1 ApacheBench

        ApacheBench（ab）是一款ApacheServer基准的测试工具，用户测试Apache Server的服务能力（每秒处理请求数），它不仅可以用户Apache的测试，还可以用于Tomcat、Nginx、lighthttp、IIS等服务器。

1.1.1 Windows版本使用

1）下载ApacheBench：by49

2）直接加压到某个目录，如图：

3）进入D:\soft\itTools\ab\Apache24\bin  bin目录

4）按住shift 鼠标右键，在此处打开命令窗口，如图：

5）输入命令：ab -c 10000 -n 100000 http://localhost:8080/webTest/  ，回车，如图：

参数说明：

-c 并发数
-n 总请求数

6）执行结果如图：

 

1.1.2 Linux版本使用

A. 安装

yum install httpd-tools

如图：

输入：Y

 

B. 查看版本号

ab -V

注意：V是大写 

如图：

 

C. 部署war包，准备环境

1）将准备好的war包上传到webapps目录

2）启动tomcat：进入tomcat的bin目录，输入命令：sh startup.sh，如图：

输入网址：http://192.168.5.128:8080/webTest/

D. 输入命令测试：ab -c 1000 -n 1000 http://localhost:8080/webTest

输出测试报告如下：

1.1.3 命令参数说明

ab -n 1000 -c 1000 -p data.json -T application/json http://localhost/search.do?page=1&pageSize=10

参数	含义描述
-n	在测试会话中所执行的请求个数，默认执行1次请求
-c	一次产生的请求个数，默认1次1个
-p	包含了需要POST的数据文件
-t	测试所进行的最大秒数，默认没有时间限制
-T	post数据所需要使用的Content-Type头信息

1.1.4 测试结果解读

1）请求输出的日志

2）服务器软件：

3）请求路径与传输字节数：

4）并发数：Concurrency Level:      1000

5）执行的请求总耗时：Time taken for tests:   1.122 seconds

6）总共请求次数：Complete requests:      1000

7）数据传输：

8）每秒执行请求数（吞吐率）：Requests per second:    891.04 [#/sec] (mean)  值越大越好

9）每个请求耗时：

第一个是针对用户而言，第二个是针对服务器而言。

10）传输字节数：

11）连接次数：

12）完成请求占比耗费时间：

以第一个为例，意思是，完成50%的请求所耗费的时间是680ms

下面用表格罗列一下：

指标	含义
Server Software	服务器软件
Server Hostname	主机名
Server Port	端口号
Document Path	测试页面
Document Length	测试页面大小
Concurrency Level	并发数
Time taken for tests	整个测试持续时间
Complete requests	完成的请求数
Failed requests	失败的请求数，这里的失败指的是请求的连接服务器、发送数据、接收数据 等环节发生异常，以及无响应后超时的情况。
Write errors	输出错误数量
Total transferred	整个场景中的网络传输量，表示所有请求的响应数据长度总和，包括每个HTTP响应 数据的头信息和正文数据长度
HTML transferred	整个场景中的HTML内容传输量，表示所有请求的响应数据中正文数据的总和
Requests per second	每秒平均处理的请求数（相当于LR中的每秒事务数），这便是我们重点关注的吞吐率，它等于 Complete requests / Time taken for tests
Time per request	每个线程处理请求平均消耗时间（相当于LR中的平均事务响应时间）用户平均请求等待时间
Transfer rate	平均每秒网络上的浏览
Percentage of the requests served within a certain time	指定时间量，执行的请求百分比

重要指标：

参数	指标说明
Requests per second	吞吐率：服务器并发处理能力的量化描述，单位是reqs/s，指的是在某个并发 用户数下单位时间内处理的请求数。 某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。 这个值表示当前机器的整体性能，值越大越好
Time per request	1. 用户平均请求等待时间：从用户角度看完成一个请求所需要的时间 2. across all concurrent requests 服务器平均请求等待时间：服务器完成一个请求所需要的时间
Concurrency Level	并发用户数

2. JVM内存参数调优

2.1 JVM参数调优

        tomcat是一款java应用，那么JVM的配置便与其运行性能密切相关，而JVM优化的重点则集中在内存分配和GC策略的调整上，因为内存会直接影响服务的运行效率和吞吐量。

        JVM垃圾回收机制则会不同程度的导致程序运行中断，我们可以根据应用程序的特点，选择不同的垃圾回收策略，调整JVM垃圾回收策略，可以极大的减少垃圾回收次数，提升垃圾回收效率，改善程序运行性能。

2.1.1 JVM内存参数

参数	参数作用	优化建议
-server	启动Server，以服务端模式运行 （启动速度慢，处理请求速度快）	建议开启
-Xms	最小堆内存	建议与-Xmx设置相同
-Xmx	最大堆内存	建议设置为可用内存的80%
-XX:MetaspaceSize	元空间初始值
-XX:MaxMetaspaceSize	元空间最大内存	默认无限
-XX:MaxNewSize	新生代最大内存	默认16M
-XX:NewRatio	年轻代和老年代的大小比值，取值为整数，默认2	不建议修改
-XX:SurvivorRatio	Eden区与survivor区大小的比值，取值为整数，默认8	不建议修改

2.1.2 Linux内存参数配置

在Windows系统的时候，我们配置在tomcat/bin/catalina.bat中，那么在Linux中，我们需要配置在tomcat/bin/catalina.sh中

JAVA_OPTS="-server -Xms2048m -Xmx2048m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m  -XX:SurvivorRatio=8"

如图：

2.1.3 查看服务器堆内存空间

1）查看当前tomcat服务器的进程id

ps -ef|grep tomcat

如图：进程ID是4776

2） 通过jmap指令查看：jmap -heap 进程id

jmap -heap 4776

如图：

3. JVM垃圾收集器

3.1 GC策略

JVM垃圾回收性能有以下两个主要的指标：

1）吞吐量：工作时间（排除GC的时间）占总时间的百分比，工作时间并不仅仅是程序运行的时间，还包括内存分配时间。

2）暂停时间：测试时间段内，由垃圾回收导致的应用程序停止响应次数/时间

在sun公司推出的HostSpotJVM中包含以下几种不同类型的垃圾收集器：

垃圾收集器	含义说明
串行收集器 （Serial Collector）	采用单线程执行所有的垃圾回收工作，适用于单核CPU服务器，无法利用多核硬件 的优势。
并行收集器 （Parallel Collector）	又称为吞吐量收集器。以并行的方式执行年轻代的垃圾回收，该方式可以显著降低垃圾 回收开销（指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态）。适用于 多处理器或多线程硬件上运行的数据量较大的应用
并发收集器 （Concurrent Collector）	以并发的方式执行大部分的垃圾回收工作，以缩短垃圾回收的暂停时间。适用于那些响应 时间由于吞吐量的应用，因为该收集器虽然最小化了暂停时间（指用户线程与垃圾收集线程 同时执行，但不一定是并行的，可能会交替执行），但是会降低应用程序的性能
CMS收集器 （Concurrent Mark Sweep Collector）	并发标记清除收集器。适用于那些更愿意缩短垃圾回收暂停时间并且负担的起与垃圾回收共享 处理器资源的应用。
G1收集器 （Garbage-First Garbage Collector）	适用于大容量内存的多核服务器，可以在满足垃圾回收暂停时间目标的同时，以最大可能性实 现高吞吐量（JDK1.7后）

不同的应用程序，对于垃圾回收会有不同的需求，JVM会根据运行的平台，服务器资源配置情况选择合适的垃圾收集器、堆内存大小以及运行时编译器。

3.2 垃圾回收器选用准则

        当JVM自适配的回收器无法满足我们的应用服务的时候，我可以手动根据需要选择合适的回收器

1）程序数据量较小，选择串行收集器

2）应用程序运行在单核处理器上且没有暂停时间要求，可交由JVM自行选择或者选择串行收集器

3）如果考虑应用程序的峰值性能，没有暂停时间要求，可以选择并行收集器

4）如果应用程序的响应时间比整体吞吐量更重要，可以选择并发收集器。

注意：不管是并行还是串行，执行垃圾回收的时候，工作线程是出于暂停状态的。

3.3 tomcat中的垃圾回收器

3.3.1 查看默认的垃圾收集器

步骤：

1）在tomcat/bin/catalina.sh的配置中，加入如下配置：

JAVA_OPTS="-Djava.rmi.server.hostname=服务器ip地址 -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.rmi.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

注意：前面我们在该文件中配置了JAVA_OPTS的，现在，直接将该配置，添加其末尾即可，如图：

2）启动tomcat

3）在本地的jdk的bin下打开jConsole工具，如图：

选择远程进程，输入服务器ip与监控的端口号，输入用户名与密码，如图：

点击连接，点击不安全的连接，如图：

在点击VM概述，如图：

从图中可以看出：

A. 新生代垃圾器：采用的是复制算法，收集了0次，总耗时0秒

B. 老年代垃圾器：采用的是标记清除压缩算法

然后，回到内存视图，点击执行GC，如图：

再回到VM概览，如图：

从图中可以看出，老年代垃圾收集器运行了1次

3.3.2 配置垃圾收集器

垃圾收集器都是配对使用的，新生代和老年代

1）GC参数

参数	描述
-XX:+UseSerialGC	启用串行收集器
-XX:+UseParallelGC	启用并行垃圾收集器，配置了该选项，那么 -XX:+UseParallelOldGC默认启用
-XX:+UseParallelOldGC	FullGC 采用并行收集器，默认禁用，设置了UseParallelGC，自动开启
-XX:+UseParNewGC	年轻代采用并行收集器，如果设置了 -XX:+UseConcMarkSweepGC选项，自动启用
-XX:ParallelGCThreads	年轻代及老年代垃圾回收使用的线程数，默认值依赖于JVM使用的CPU个数
-XX:+UseConcMarkSweepGC	对于老年代，启用CMS垃圾收集器，当并行收集器无法满足应用的延迟需求的时候，推荐使用 CMS或G1收集器，启用该项后，-XX:+UseParNewGC 自动启用
-XX:+UseG1GC	启用G1收集器，G1是服务器类型的收集器，用于多核、大内存的机器，它在保持高吞吐量的情况下，高概率满足GC暂停时间的目标

我们可以在测试的时候，将JVM参数调整之后，将GC的信息打印出来，便于为我们进行参数调整提供依据，具体参数如下：

选项	描述
-XX:+PrintGC	打印每次GC的信息
-XX:+PrintGCApplicationConcurrentTime	打印最后一次暂停之后所经过的时间，即响应并执行的时间
-XX:+PrintGCApplicationStoppedTime	打印GC时，应用程序暂停的时间
-XX:+PrintGCDateStamps	打印每次GC的日期戳
-XX:+PrintGCDetails	打印每次GC的详细信息
-XX:+PrintGCTaskTimeStamps	打印每个GC工作线程任务的时间戳
-XX:+PrintGCTimeStamps	打印每次GC的时间戳

2）配置

在tomcat/bin/catalina.sh脚本中，追加如下配置：

JAVA_OPTS="-XX:+UseParallelGC -XX:+PrintGCDetails"

注意：同理，这里因为上面已经配置过了JAVA_OPTS了，所以直接追加到末尾即可，这里，我写在内存参数后面，如图：

重启tomcat，重启jConsole，点击内存页签的执行DC，控制台输出GC信息，如图：

其中，蓝色部分为垃圾回收器的名称

4. Tomcat配置调优

        对于tomcat配置的优化，一般主要修改的就是链接器这块的配置，该配置位于tomcat/conf/server.xml文件中，配置链接器，可以提升应用服务器的性能。

参数说明：

参数	说明
maxConnections	最大连接数，当达到该值后，服务器接收不但不会处理更多的请求，额外的请求将会阻塞直到连接数低于 maxConnections。可通过ulimit -a查看服务器限制。对于CPU要求较高（计算型）的应用时，建议不要配置过大； 对于CPU要求不是特别高时，建议配置在2000左右（受服务器性能影响）。当然这个需要服务器硬件支持。
maxThreads	最大线程数，需要根据服务器的硬件情况，进行一个合理的设置
acceptCount	最大排队等待数，当服务器接收的请求数量达到maxConnections的时候，此时tomcat会将后面的请求，存放 在任务队列中进行排序，acceptCount指的就是任务队列中排队等待的请求数。一台Tomcat的最大请求处理数量， 是maxConnections + acceptCount

如图：