利用apache tomcat性能测试

Tomcat的利用默认配置从来就不是为高并发准备的。上个月我把一个Spring Boot应用丢到生产环境，测试用JMeter压了200个并发线程，利用结果吞吐量惨不忍睹——每秒才处理120个请求，测试而CPU利用率还不到30%。利用问题不在代码，测试在于Tomcat的利用线程池和连接器参数完全是出厂状态。

先看最关键的测试server.xml里的Executor配置。默认的利用线程池最大只有200个线程，但这不代表你该把它调到2000。测试线程多了上下文切换的利用开销反而拖垮性能。我的测试经验是：先压测，观察线程池活跃度曲线，利用如果持续顶到上限且响应时间飙升，测试再逐步增加maxThreads，利用每次加50，看TPS变化。前几天帮朋友调一个电商后台，把maxThreads从200调到400，TPS从800涨到1400，但再调到600反而跌回1200——过犹不及。

连接器参数更隐蔽。acceptCount控制的是等待队列长度，默认100，如果请求量瞬间爆发，队列满了直接拒绝连接。但设太大也有风险，客户端等太久会超时重试，反而加重服务器负担。我习惯把acceptCount设成maxThreads的四分之一，再配合connectionTimeout调到5000毫秒以内。另外记得开启tcpNoDelay，关闭Nagle算法，小请求的延迟能降20%左右——这对那些频繁的API调用特别明显。

AJP连接器是很多人忽略的坑。如果用了Nginx做前端代理，默认走HTTP协议，但AJP的二进制协议开销更小。我做过对比，同一台机器上，AJP比HTTP代理的吞吐量高15%。不过要注意，AJP的packetSize默认8192字节，如果响应头太大（比如带了很多Cookie），会报错。把packetSize调到65536，一劳永逸。

别光盯着连接器，JVM堆内存和GC策略直接决定Tomcat能撑多久。用G1垃圾回收器，把-Xms和-Xmx设成相同值，避免运行时动态扩容。我见过一个极端案例：堆内存设了4GB，但NewRatio没调，年轻代太小，对象频繁晋升到老年代，Full GC每30秒一次，TPS直接掉到地板。后来把-XX:NewRatio=2改成=1，年轻代翻倍，Full GC频率降到两分钟一次。

压测时还要注意监控线程池的currentThreadsBusy，这是最直接的瓶颈指标。如果这个值长期高于maxThreads的80%，说明线程不够用；如果低于50%但TPS上不去，那瓶颈可能在数据库或外部API，别傻乎乎继续调Tomcat。有次我调了半天参数没效果，最后发现是后端MySQL的max_connections满了，Tomcat线程全在等数据库连接池释放。

最后一个容易被忽视的细节：session持久化。如果应用不需要分布式会话，把Context里的manager去掉，省掉序列化和存储开销。压测时用curl -I看响应头，如果每次请求都带Set-Cookie，说明session在频繁创建，多半是代码里new了HttpSession没复用。这种问题调Tomcat没用，得改代码。

调优是个反复验证的过程。别信网上那些“万能配置模板”，每台机器的CPU核数、IO性能、应用特征都不一样。核心原则就一条：压测，看指标，改一个参数，再压测。我自己的记录是，从默认配置到最优配置，通常需要五到六轮调整，每次只动一个变量，否则出了问题根本定位不到原因。