avatar

tomcat源码剖析

Tomcat对Https的支持

https简介

Https是用来加强数据传输安全的。
HTTPS(全称:Hyper Text Transfer Protocol over SercureSocket Layer),是以安全为目的的HTTP通道,在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS在HTTP的基础下加入了SSL层,HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL。HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层(在HTTP与TCP之间)。这个系统提供了身份验证与加密通讯方法。它被广泛用于万维网安全敏感的通讯上。
HTTP是超文本传输协议,明文传输,传输不安全。https在传输数据的时候会对数据进行加密。

HTTPS与HTTP的主要区别

  • HTTPS使用的时候需要使用到电子政务认证授权机构(CA)申请SSL证书
  • HTTP默认使用的是8080端口,HTTPS默认使用的是8443端口
  • HTTPS则是具有SSL加密的安全性传输协议,对数据的传输进行加密,效果上相当于HTTP的升级版
  • HTTP的连接是无状态的,不安全的;HTTPS协议是由SSL+HTTPS协议侯建的可进行加密传输、身份认证的网络协议,比HTTP协议安全

Tomcat性能优化

系统性能的衡量指标,主要是响应时间和吞吐量:

  • 响应时间: 执行某个操作的耗时
  • 吞吐量:系统在给定时间内能够支持的事务数量,单位为TPS(Transactions PerSecound的缩写,也就是事务数/秒),一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程

    虚拟机运行优化(参数调整)

    Tomcat优化的两个方面:
  • JVM虚拟机优化(优化内存模型)
  • Tomcat自身配置的优化(比如是否使用了共享线程池,或者NIO模型等)
    java虚拟机的运行优化主要是内存分配和垃圾回收策略的优化:
  • 内存直接应县辜负我的运行效率和吞吐量
  • JVM垃圾回收机制则会不同程度的导致程序运行中断(我们可以选择不同的垃圾回收策略,调整JVM垃圾回收策略,可以极大的减少垃圾回收次数,提升垃圾回收效率,改善程序运行性能)

JVM虚拟机内存相关参数

参数 参数作用 优化建议
-server 启动Server,以服务端模式运行 服务端模式建议开启
-Xms 最小堆内存 建议与-Xmx设置相同
-Xmx 最大堆内存 建议设置为可用内存的80%
-XX:MetaspaceSize 元空间初始值
-XX:MaxMetaspaceSize 元空间最大内存 默认无限
-XX:NewRatio 年轻代和老年代大小比值,取值为整数,默认为2 不需要修改
-XX:SurvivorRatio Eden区与Survivor区大小的比值,取值为整数,默认为8 不需要修改
在配置的时候需要在tomcat的catalina.sh或者catalina.bat文件中添加java参数
JAVA_OPTS="-server -Xms2048m -Xmx2048m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m"
配置完成虚拟机参数以后,我们可以通过jmap命令查看java虚拟机内部的一些配置
jmap -heap  进程号
这样可以查到该java虚拟机的一些配置以及使用了多少
 jmap -heap 10928
Attaching to process ID 10928, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.291-b10

using thread-local object allocation.
Parallel GC with 8 thread(s)

Heap Configuration:
MinHeapFreeRatio = 0
MaxHeapFreeRatio = 100
MaxHeapSize = 4263510016 (4066.0MB)
NewSize = 89128960 (85.0MB)
MaxNewSize = 1420820480 (1355.0MB)
OldSize = 179306496 (171.0MB)
NewRatio = 2
SurvivorRatio = 8
MetaspaceSize = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB
G1HeapRegionSize = 0 (0.0MB)

Heap Usage:
PS Young Generation
Eden Space:
capacity = 67108864 (64.0MB)
used = 34052512 (32.475006103515625MB)
free = 33056352 (31.524993896484375MB)
50.742197036743164% used
From Space:
capacity = 11010048 (10.5MB)
used = 10995800 (10.486412048339844MB)
free = 14248 (0.01358795166015625MB)
99.87059093656994% used
To Space:
capacity = 11010048 (10.5MB)
used = 0 (0.0MB)
free = 11010048 (10.5MB)
0.0% used
PS Old Generation
capacity = 179306496 (171.0MB)
used = 2155600 (2.0557403564453125MB)
free = 177150896 (168.9442596435547MB)
1.2021873429504752% used

16253 interned Strings occupying 1603736 bytes.

垃圾回收策略

垃圾回收性能指标

  • 吞吐量:工作时间(排除GC时间)占总时间的百分比,工作时间并不仅是程序运行的时间,还包含内存分配时间
  • 暂定时间:由垃圾回收导致的应用程序停止相应次数/时间
    垃圾回收器
  • 串行收集器(Serial Collector): 单线程执行所有的垃圾回收工作,适用于单核CPU服务器
  • 并行收集器(Parallel Collector): 又称为吞吐量收集器(关注吞吐量),以并行的方式执行年轻代的垃圾回收,该方式可以显著降低垃圾回收的开销(指多条垃圾收集线程并行工作,但此时用户线程仍然处于等待状态)。适用于多处理器或者多线程硬件上运行的数据量较大的应用
  • 并发收集器(Concurrent Collector):以并发的方式执行大部分垃圾回收工作,以缩短垃圾回收的暂停时间。适用于那些响应时间优先于吞吐量的应用,因为该收集器最小化了暂停时间(指用户线程与垃圾收集线程同时执行,但不一定是并行的,可能会交替进行),但是会降低应用程序的性能
  • CMS收集器(Concurrent Mark Sweep Collector): 并发标记清除收集器,适用于那些更愿意缩短垃圾回收暂定时间并且负担的起与垃圾回收共享处理器资源的应用
  • G1收集器(Garbage-First Garbage Collector):适用于大容量内存的多核服务器,可以在满足垃圾回收暂停时间目标的同时,以最大可能性实现高吞吐量(JDK1.7以后)
  • 可以通过jdk提供的工具JConsole来查看使用的是什么垃圾收集器
    垃圾回收参数
    参数 描述
    -XX:+UseSerialGC 启动串行收集器
    -XX:+UseParallelGC 启用并行垃圾收集器,配置了该选项,那么-XX:UseParallelOldGC默认开启
    -XX:+UseParNewGc 年轻代采用并行收集器,如果设置了-XX:UseConcMarkSweepGC选项。自动开启
    -XX:ParallelGCThreads 年轻代以及老年代垃圾回收使用的线程数。默认值依赖于JVM使用的CPU个数
    -XX:UseConcMarkSweepGC 对于老年代,启动CMS垃圾收集器。当并行收集器无法满足应用的延迟需求时,推荐使用CMS或者G1收集器。启动该选项后,-XX:UseParNewGC自动启动
    -XX:UseG1GC 启用G1收集器,G1是服务器类型的收集器,用于多核、大内存的机器。它在保持高吞吐量的情况下,高概率满足GC暂停时间的目的

Tomcat自身调优

  • 调整tomcat线程池:可以创建统一的线程池供tomcat使用

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

  • 禁用AJP连接器,将server.xml中ajp协议部分注释掉即可

  • 调整IO模式:Tomcat8之前的版本默认使用的是BIO,对于每个请求都会创建一个线程来处理,不适合高并发,Tomcat以后的版本默认使用NIO模型。当Tomcat并发性能有较高要求或者出现瓶颈时,我们可以尝试使用APR模式,是从操作系统级别解决异步IO问题。使用时需要在操作系统上安装APR和Native(因为APR原理是使用JNI技术调用操作系统底层的IO接口)

  • 动静分离:可以使用Nginx——Tomcat相结合的部署方案,Nginx负责静态资源访问,Tomcat负责jsp等动态资源访问处理(因为Tomcat不擅长处理静态资源)

文章作者: zenshin
文章链接: https://zlh.giserhub.com/2021/11/13/cl35o0mr3003lp4tgblnn5nup/
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 zenshin's blog
打赏
  • 微信
    微信
  • 支付宝
    支付宝

评论