大家好，欢迎来到停止重构的频道。
本期讨论Tomcat的性能调优。
当然，如果不是使用Java开发或者Tomcat也没关系，因为后端服务软件的调优思路基本是相同的。
我们常遇到一个问题：Tomcat长时间运行会内存枯竭退出，或者压力测试下Tomcat并不能完全使用服务器的物理性能，这些都是因为没对Tomcat进行优化的结果。
我们按这样的顺序介绍：
明确性能指标
服务器硬件选择
单个Tomcat服务性能调优
集群方案
明确性能指标
在调优之前需要先明确性能指标，根据往期《性能指标》整体系统的性能指标是并发量、吞吐量、错误率、响应时间。
在调试单个服务时，根据往期《调优基本思路》的结论，只需要明确吞吐量即可，如果整个系统的吞吐量指标为rps，则Tomcat吞吐量最好为rps。
不过，Tomcat的最终吞吐量与业务功能是强关联的，且后端接口都会依赖数据服务、云计算服务等服务，也就是说，单单测试Tomcat性能并无实际意义。
而且，由于Tomcat的扩展是很容易的，所以一般Tomcat不需要单独测试，直接测试网站系统整体性能即可，网站系统性能测试方法可参考往期《性能测试》。
那么，Tomcat服务性能怎么判断是否足够呢？一般是观察Tomcat服务器与其他服务器的负载情况，负载情况分析可参考往期《负载分析》。
例如，如果在整体性能测试时，Tomcat的负载是满的（如CPU、内存、带宽使用率等），但其他服务的负载是未满的，则说明Tomcat服务存在性能瓶颈，这时可以考虑增加Tomcat服务器，或增加硬件配置。
如果条件允许的话，最好在增加Tomcat服务器数量或硬件配置后再次进行测试验证，因为增加一台Tomcat服务后，吞吐量并不一定等于原来的两倍。
至于Tomcat最大并发量的设置，仍然可以低于整体系统的最大并发要求，让一些请求进入等待队列更有利于并发性能，不过这个并发值我们是推荐在整体系统测试时通过多次修改测试而定。
服务器硬件选择
Tomcat与其他后端服务一样，是I/O密集型的服务，它更多是在等待MySQL、Redis这些服务完成任务。所以硬件配置不需要太高，一般Cpu和内存配比为1:2。
另外，Tomcat服务器网络带宽也是不容忽视的，特别是拥有上传下载功能的后端服务。
单个Tomcat服务性能调优
接下来是对单个Tomcat服务调优。在这之前，需要先调优服务器内核参数，调优方法可以参考往期《内核参数调优》，Tomcat的工作原理可参考往期《后端工作原理》。
Tomcat调优有两个基本点。
一是JVM内存调优，经常遇到一个问题，长时间运行Tomcat后会崩溃退出。因为tomcat（Catalina部分）实际上是一个java程序，如果不限制内存的话，会因为内存枯竭自动退出。
另一个是线程池，线程池一般来说配置或就行，过多的线程反而让Tomcat性能更低。
当然线程数最好经过多次修改测试后再确定。另外，模式一般选用Nio模式，当然，如果条件允许，最好使用Apr模式，但是安装起来比较麻烦。
集群方案
严格意义上讲，tomcat本身是没有集群方案的，但得益于其一般是无状态的特性，在前面增加一个负载均衡（Nginx等），即可实现集群化。
这里需要特别说明的是，增加Tomcat服务器数量的意义：一是为了防止某个Tomcat宕机；二是防止单个Tomcat服务成为系统的性能瓶颈。
至于微服务无限扩展这个事，说到底就是与无限扩展Tomcat是一样的，扩展确实能扩展，但是性能并不会因为多一个Tomcat而上升。毕竟整体性能最后还是要看MySQL等数据服务或其他服务的性能。
那么，这里还有一个问题，加上负载均衡后，一个Tomcat宕机后，另外的Tomcat仍然可以正常处理业务。
那负载均衡挂了呢？这个问题我们将在下一期Nginx调优中讲解。
总结
在本期的最后，我们还想讨论一个问题，Java、GO、PHP、Node哪个开发语言具有更高的性能？Tomcat、WebLogic哪个服务软件的性能更高？
其实这些问题都是没有意义的。
正如我们不提倡单独测试Tomcat性能一样，因为网站系统的性能最终是局限在数据服务等其他服务的性能上的。而后端服务也只是作为网站系统整合其他服务的中央调度中心。
所以，如果仅仅因为性能选用不熟悉的后端开发语言或服务软件的话，往往得不偿失。