6. Tomcat对Https的支持及Tomcat性能优化策略
6.1 Tomcat对HTTPS的支持
Https是用来加强数据传输安全的
6.1.1HTTPS简介
HTTPS (全称:Hyper Text Transfer Protocol over SecureSocket Layer),是以安全为目标的 HTTP 通道,在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 [1] 。HTTPS 在HTTP 的基础下加入SSL,HTTPS 的安全基础是 SSL,因此加密的详细内容就需要 SSL。 HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层(在 HTTP与 TCP 之间)。这个系统提供了身份验证与加密通讯方法。它被广泛用于万维网上安全敏感的通讯,例如交易支付等方面 [2] 。
http超文本传输协议,明文传输,传输不安全,Https在传输数据的时候对数据进行加密
HTTPS和HTTP的主要区别
- HTTPS协议使用时需要到电子商务认证授权机构(CA)申请SSL证书
- HTTP默认使用8080端口,HTTPS默认使用8443端口
- HTTPS则是使用具有SSL加密的安全性传输协议,对数据的传输进行加密,效果上相当于HTTP的升级版
- HTTP连接时无状态的,不安全的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络安全协议,比HTTP协议安全
HTTPS工作原理
6.1.2 Tomcat对HTTPS的支持
-
使⽤ JDK 中的 keytool ⼯具⽣成免费的秘钥库⽂件(证书)。
keytool -genkey -alias lagou -keyalg RSA -keystore lagou.keystore
-
配置conf/server.xml
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" schema="https" secure="true" SSLEnabled="true" > <SSLHostConfig> <Certificate certificateKeystoreFile="D:\Project\JavaStudyProject\LagouProject\5Tomcat\apache-tomcat-8.5.50-src\source\conf\lagou.keystore" certificateKeystorePassword="lagou123" type="RSA" /> </SSLHostConfig> </Connector>
-
使⽤https协议访问8443端⼝(https://localhost:8443)
6.2 Tomcat性能优化策略
系统性能的衡量指标,主要是响应时间和吞吐量
- 响应时间:执行某个操作的耗时
- 吞吐量:系统在给定时间内能够支持的事务数量,单位为TPS(Transactions PerSecond的缩写,也就是事务数/秒,一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程)
Tomcat优化从两个方面进行
- JVM虚拟机优化(优化内存模型)
- Tomcat自身配置优化(比如是否使用了共享线程池?IO模型?)
学习优化原则
提供给大家优化思路,没有明确的参数值直接使用,必须根据自己的真实生产环境进行调整,调优是一个过程。
6.2.1虚拟机运行优化(参数调整)
java虚拟机的运行优化主要是内存分配和垃圾回收策略的优化:
- 内存直接影像服务的运行效率和吞吐量
- 垃圾回收机制会不同程度地导致程序运行中断(垃圾回收策略不同,垃圾回收次数和回收效率都是不同的)
-
java虚拟机内存相关参数
参数 参数作用 优化建议 -server 启动Server,以服务端模式运⾏ 服务端模式建议开启 -Xms 最⼩堆内存 建议与-Xmx设置相同 -Xmx 最⼤堆内存 建议设置为可⽤内存的80% -XX:MetaspaceSize 元空间初始值 -XX:MaxMetaspaceSize 元空间最⼤内存 默认⽆限 -XX:NewRatio 年轻代和⽼年代⼤⼩⽐值,取值为整数,默认为2 不需要修改 -XX:SurvivorRatio Eden区与Survivor区⼤⼩的⽐值,取值为整数,默认为8 不需要修改 -
JVM内存模型回顾
参数调整示例
JAVA_OPTS="-server -Xms2048m -Xmx2048m -XX:MetaspaceSize=256m -
XX:MaxMetaspaceSize=512m"
调整后查看可使⽤JDK提供的内存映射⼯具
- 垃圾回收(GC)策略
垃圾回收性能指标
- 吞吐量:⼯作时间(排除GC时间)占总时间的百分⽐, ⼯作时间并不仅是程序运⾏的时间,还包 含内存分配时间。
- 暂停时间:由垃圾回收导致的应⽤程序停⽌响应次数/时间。
垃圾收集器
-
串行收集器(Serial Collector)
单线程执行所有的垃圾回收工作,适用于单核CPU服务器
工作进程终止–》(单线程)垃圾回收线程进行垃圾回收–》工作进程继续
-
并行收集器(Parallel Collector)
工作进程终止–》(多线程)垃圾回收线程进行垃圾收集–》工作进程继续
又称为吞吐量收集器(关注吞吐量),以并行的方式执行年轻代的垃圾回收,该方法可以显著降低垃圾回收的开销(指多条垃圾收集线程并行工作,但此时用户线程仍处于等待状态)。适用于多处理器或多线程硬件上运行的数据量较大的应用。
-
并发收集器(Concurrent Collector)
以并发的方式执行大部分垃圾回收工作,以缩短垃圾回收的暂停时间。适用于哪些响应时间优先于吞吐量的应用,因为改收集器虽然最小化了暂停时间(指用户线程与垃圾收集线程同时执行,但不一定视并行的,可能会交替进行),但是会降低应用程序的性能。
-
CMS收集器(Concurrent Mark Sweep Collector)
并发标记清除收集器,适用于哪些更愿意缩短垃圾回收暂停时间并且负担得起与垃圾回收共享处理器资源的应用
-
G1收集器(Garbage-First Garbage Collector)
适用于大容量内存的多核服务器,可以在满足垃圾回收暂停时间目标的同事,以最大可能性实现高吞吐量(JDK1.7之后)
垃圾回收器参数
参数 | 描述 |
---|---|
-XX:+UseSerialGC | 启⽤串⾏收集器 |
-XX:+UseParallelGC | 启⽤并⾏垃圾收集器,配置了该选项,那么 -XX:+UseParallelOldGC默认 启⽤ |
-XX:+UseParNewGC | 年轻代采⽤并⾏收集器,如果设置了 -XX:+UseConcMarkSweepGC选 项,⾃动启⽤ |
-XX:ParallelGCThreads | 年轻代及⽼年代垃圾回收使⽤的线程数。默认值依赖于JVM使⽤的CPU个 数 |
- XX:+UseConcMarkSweepGC(CMS) | 对于⽼年代,启⽤CMS垃圾收集器。 当并⾏收集器⽆法满⾜应⽤的延迟需 求是,推荐使⽤CMS或G1收集器。启⽤该选项后, -XX:+UseParNewGC ⾃动启⽤。 |
-XX:+UseG1GC | 启⽤G1收集器。 G1是服务器类型的收集器, ⽤于多核、⼤内存的机器。 它在保持⾼吞吐量的情况下,⾼概率满⾜GC暂停时间的⽬标。 |
在bin/catalina.sh的脚本中 , 追加如下配置 :
JAVA_OPTS="-XX:+UseConcMarkSweepGC"
6.2.2 Tomcat配置调优
Tomcat自身相关的调优
-
调整Tomcat线程池
-
调整Tomcat的连接器
调整tomcat/conf/server.xml 中关于链接器的配置可以提升应⽤服务器的性能。
参数 说明 maxConnections 最⼤连接数,当到达该值后,服务器接收但不会处理更多的请求, 额外的请 求将会阻塞直到连接数低于maxConnections 。可通过ulimit -a 查看服务器 限制。对于CPU要求更⾼(计算密集型)时,建议不要配置过⼤ ; 对于CPU要求 不是特别⾼时,建议配置在2000左右(受服务器性能影响)。 当然这个需要服 务器硬件的⽀持 maxThreads 最⼤线程数,需要根据服务器的硬件情况,进⾏⼀个合理的设置 acceptCount 最⼤排队等待数,当服务器接收的请求数量到达maxConnections ,此时 Tomcat会将后⾯的请求,存放在任务队列中进⾏排序, acceptCount指的 就是任务队列中排队等待的请求数 。 ⼀台Tomcat的最⼤的请求处理数量, 是maxConnections+acceptCount -
禁用AJP连接器
-
调整IO模式
Tomcat8之前的版本默认使⽤BIO(阻塞式IO),对于每⼀个请求都要创建⼀个线程来处理,不适 合⾼并发;Tomcat8以后的版本默认使⽤NIO模式(⾮阻塞式IO)
当Tomcat并发性能有较⾼要求或者出现瓶颈时,我们可以尝试使⽤APR模式,APR(Apache Portable Runtime)是从操作系统级别解决异步IO问题,使⽤时需要在操作系统上安装APR和Native(因为APR 原理是使⽤使⽤JNI技术调⽤操作系统底层的IO接⼝) -
动静分离
可以使⽤Nginx+Tomcat相结合的部署⽅案,Nginx负责静态资源访问,Tomcat负责Jsp等动态资 源访问处理(因为Tomcat不擅⻓处理静态资源)。