2020-08-14 12:47 已编辑滴滴出行_网约车_后端开发

关注

Tomcat8优化

Tomcat配置优化

部署安装tomcat8

下载并安装：
https://tomcat.apache.org/download-80.cgi

cd apache‐tomcat‐8.5.34/conf
修改配置文件，配置tomcat的管理用户
vim tomcat‐users.xml
写入如下内容：

<role rolename="manager"/>
<role rolename="manager-gui"/>
<role rolename="admin"/>
<role rolename="admin-gui"/>
<user username="tomcat" password="tomcat" roles="admin-gui,admin,manager-gui,manager"/>

如果是tomcat7，配置了tomcat用户就可以登录系统了，但是tomcat8中不行，还需要修改另一个配置文件，否则访问不了，提示403
vim webapps/manager/META‐INF/context.xml
将<Valve的内容注释掉

<Context antiResourceLocking="false" privileged="true" >
<!‐‐ <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" /> ‐‐>
<Manager sessionAttributeValueClassNameFilter="java\.lang\. (?:Boolean|Integer|Long|Number|String)|org\.apache\.catalina\.filters\.Cs rfPreventionFilter\$LruCache(?:\$1)?|java\.util\.(?:Linked)?HashMap"/>
</Context>

打开浏览器访问
点击“Server Status”，输入用户名、密码进行登录，tomcat/tomcat

进入之后即可看到服务的信息

禁用AJP连接

在服务状态页面中可以看到，默认状态下会启用AJP服务，并且占用8009端口

什么是AJP呢？

AJP（Apache JServer Protocol）
AJPv13协议是面向包的。WEB服务器和Servlet容器通过TCP连接来交互；为了节省SOCKET创建的昂贵代价，WEB服务器会尝试维护一个永久TCP连接到servlet容器，并且在多个请求和响应周期过程会重用连接

我们一般是使用Nginx+tomcat的架构，所以用不着AJP协议，所以把AJP连接器禁用。
修改conf下的server.xml文件，将AJP服务禁用掉即可。

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

重启tomcat，查看效果

可以看到AJP服务以及不存在了

执行器（线程池）

在tomcat中每一个用户请求都是一个线程，所以可以使用线程池提高性能。
修改server.xml文件：

<!‐‐将注释打开‐‐>
<Executor name="tomcatThreadPool" namePrefix="catalina‐exec‐" maxThreads="500" minSpareThreads="50" prestartminSpareThreads="true" maxQueueSize="100"/>
<!‐‐ 参数说明： maxThreads：最大并发数，默认设置 200，一般建议在 500 ~ 1000，根据硬件设施和业 务来判断 minSpareThreads：Tomcat 初始化时创建的线程数，默认设置 25 prestartminSpareThreads： 在 Tomcat 初始化的时候就初始化 minSpareThreads 的 参数值，如果不等于 true，minSpareThreads 的值就没啥效果了 maxQueueSize，最大的等待队列数，超过则拒绝请求 ‐‐>
<!‐‐在Connector中设置executor属性指向上面的执行器‐‐>
<Connector executor="tomcatThreadPool" port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

保存退出，重启tomcat，查看效果。

在页面中显示最大线程数为-1，这个是正常的，仅仅是显示的问题，实际使用的指定的值。

3种运行模式

tomcat的运行模式有3种：

bio（阻塞）
默认的模式,性能非常低下,没有经过任何优化处理和支持.
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)更好的并发运行性能。
apr
安装起来最困难,但是从操作系统级别来解决异步的IO问题,大幅度的提高性能.

推荐使用nio，不过，在tomcat8中有最新的nio2，速度更快，建议使用nio2

设置nio2：

<Connector executor="tomcatThreadPool" port="8080" protocol="org.apache.coyote.http11.Http11Nio2Protocol" connectionTimeout="20000" redirectPort="8443" />

可以看到已经设置为nio2了。

使用Apache JMeter进行测试

Apache Jmeter是开源的压力测试工具，我们借助于此工具进行测试，将测试出tomcat的吞吐量等信息。

下载安装

下载地址：http://jmeter.apache.org/download_jmeter.cgi

设置语言为简体中文。
语言修改完成。

创建首页的测试用例

第一步：保存测试用例
第二步：添加线程组，使用线程模拟用户的并发

1000个线程，每个线程循环10次，也就是tomcat会接收到10000个请求。

第三步：添加http请求

第四步：添加请求监控

启动、进行测试

聚合报告
在聚合报告中，重点看吞吐量
调整tomcat参数进行优化
通过上面测试可以看出，tomcat在不做任何调整时，吞吐量为73次/秒。

调整tomcat参数进行优化

禁用AJP服务

之前的结果

优化后的结果

可以发现各项指标都有所提升
当然了，测试不一定准确，需要多测试几次才能看出是否有提升

设置线程池

通过设置线程池，调整线程池相关的参数进行测试tomcat的性能。
最大线程数为1000，初始为200

<Executor name="tomcatThreadPool" namePrefix="catalina‐exec‐" maxThreads="500" minSpareThreads="50" prestartminSpareThreads="true"/>

测试结果

可以看出吞吐量有少量提升
线程数越多并不会一直造成性能的提升
<mark>需要多次的测试，才可以找到最优的线程取值</mark>

设置最大等待队列数

默认情况下，请求发送到tomcat，如果tomcat正忙，那么该请求会一直等待。这样虽然可以保证每个请求都能请求到，但是请求时间就会边长。
有些时候，我们也不一定要求请求一定等待，可以设置最大等待队列大小，如果超过就不等待了。这样虽然有些请求是失败的，但是请求时间会虽短。典型的应用：12306。
这是对系统的一个保护

测试结果

发现错误率特别高
牺牲了错误率，但是性能极大的提升

设置nio2的运行模式

<Connector executor="tomcatThreadPool" port="8080" protocol="org.apache.coyote.http11.Http11Nio2Protocol" connectionTimeout="20000" redirectPort="8443" />

结果

可以看到，平均响应时间有缩短，吞吐量有提升，可以得出结论：nio2的性能要高于nio。

调整JVM参数进行优化

在bin/catalina.sh设置

设置并行垃圾回收器

JAVA_OPTS="-XX:+UseParallelGC -XX:+UseParallelOldGC -Xms64m -Xmx512m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps ‐XX:+PrintGCDateStamps ‐XX:+PrintHeapAtGC ‐Xloggc:../logs/gc.log"

测试结果与默认的JVM参数结果接近。

查看gc日志文件

将gc.log文件上传到gceasy.io查看gc中是否存在问题。

问题一：
在报告中显示，在5次GC时，系统所消耗的时间大于用户时间，这反应出的服务器的性能存在瓶颈，调度CPU等资源所消耗的时间要长一些。

问题二：

可以关键指标中可以看出，吞吐量表现不错，但是gc时，线程的暂停时间稍有点长

问题三：

通过GC的统计可以看出：

年轻代的gc有74次，次数稍有多，说明年轻代设置的大小不合适需要调整
FullGC有8次，说明堆内存的大小不合适，需要调整

问题四：

从GC原因的可以看出，年轻代大小设置不合理，导致了多次GC。

JAVA_OPTS="‐XX:+UseParallelGC ‐XX:+UseParallelOldGC ‐Xms128m ‐Xmx1024m ‐XX:NewSize=64m ‐XX:MaxNewSize=256m ‐XX:+PrintGCDetails ‐XX:+PrintGCTimeStamps ‐XX:+PrintGCDateStamps ‐XX:+PrintHeapAtGC ‐Xloggc:../logs/gc.log"

将初始堆大小设置为128m，最大为1024m
初始年轻代大小64m，年轻代最大256m

从测试结果来看，吞吐量以及响应时间均有提升。

设置G1垃圾回收器

设置了最大停顿时间100毫秒，初始堆内存128m，最大堆内存1024m

JAVA_OPTS="‐XX:+UseG1GC ‐XX:MaxGCPauseMillis=100 ‐Xms128m ‐Xmx1024m ‐XX:+PrintGCDetails ‐XX:+PrintGCTimeStamps ‐XX:+PrintGCDateStamps ‐XX:+PrintHeapAtGC ‐Xloggc:../logs/gc.log"