如何对Apache Tomcat应用做压力测试？用JMeter遇截断块异常

我来帮你梳理下Tomcat应用压力测试的完整思路，还有你遇到的JMeter分块数据截断错误的具体解决办法～

一、Tomcat压力测试的核心步骤与工具选择 #

首先得明确你的测试目标：比如要验证多少并发下系统能稳定运行、响应时间是否符合要求、吞吐量能达到多少，还有高并发下的错误率阈值。常用的测试工具各有侧重，你可以根据场景选：

• Apache Bench（ab）：轻量级命令行工具，适合快速做简单接口的并发测试，比如输入ab -n 1000 -c 100 http://your-tomcat-url/就能快速生成100并发、1000次请求的测试结果。
• JMeter：功能最全面的可视化工具，支持复杂场景（比如登录态保持、多接口串联），你已经在使用它，适合做深度的性能测试。
• Gatling：基于Scala的高性能测试工具，自带实时报表，高并发下资源消耗比JMeter低，适合超大规模的压力测试。

测试前一定要做准备工作：

• 先优化Tomcat的基础配置：比如调整server.xml里Connector的maxThreads（最大工作线程）、acceptCount（等待队列长度），设置合理的connectionTimeout；给JVM分配足够的内存（比如set JAVA_OPTS=-Xms2g -Xmx4g），避免Tomcat先因为内存或线程瓶颈挂掉。
• 准备好监控工具：用JConsole/VisualVM监控Tomcat的JVM状态（堆内存、GC情况），用Tomcat自带的Manager页面查看当前连接数、线程数，方便排查瓶颈。

二、解决JMeter的TruncatedChunkException错误 #

你碰到的这个错误是说服务器返回的分块编码响应被截断了，预期的分块大小和实际收到的不一致，大概率是高并发下服务器、JMeter或者网络环节出了问题，按下面的步骤排查：

1. 先排查Tomcat服务器端的问题 #

• 查看Tomcat的catalina.out日志，有没有内存溢出（OutOfMemoryError）、线程池耗尽的报错，这些会导致Tomcat无法完整生成响应就断开连接。
• 检查server.xml的Connector配置：
  • 确保maxThreads和acceptCount设置足够（比如并发1000的话，maxThreads设成200-500，acceptCount设成1000），避免请求被拒绝。
  • 把connectionTimeout调大一点，比如从默认的20000（20秒）改成30000（30秒），高并发下服务器处理请求需要更多时间。
  • 检查compression相关配置，如果开启了compression="on"，确保compressionMinSize设置合理，避免小响应也被压缩导致分块错误。

2. 调整JMeter的配置参数 #

• 延长请求超时时间：在HTTP请求采样器的“高级”标签里，把“连接超时”和“响应超时”都改成30000以上（比如60000，即1分钟），默认的超时时间太短，高并发下服务器响应慢就会导致截断。
• 调整HTTP客户端实现：在JMeter的jmeter.properties配置文件里，把httpclient4.retrycount设置为0（避免重试导致的分块混乱），或者试试切换到Java原生的HTTP客户端实现（把httpclient.config改成java），不同客户端对分块编码的处理逻辑有差异。
• 给JMeter扩容内存：JMeter本身如果内存不足，处理大量响应数据时会出问题。修改jmeter.bat（Windows）或jmeter.sh（Linux）里的HEAP参数，比如改成HEAP="-Xms1g -Xmx4g"，根据你的测试机器配置来调整。
• 关闭不必要的采样器配置：高并发测试时，不要开启“保存响应数据”“保存响应头”这类消耗资源的选项，减少JMeter的IO和内存压力。

3. 排查网络与中间件问题 #

• 检查测试机器和Tomcat服务器之间的网络稳定性，用ping或mtr工具测试是否有丢包、延迟过高的情况，网络丢包会直接导致响应分块截断。
• 如果Tomcat前面有反向代理（比如Nginx），检查代理的超时配置：比如Nginx的proxy_read_timeout要设置足够长，proxy_buffering开启避免代理提前断开连接。

4. 尝试分布式测试 #

如果单台JMeter机器的并发上限不够，导致自身成为瓶颈，可以用JMeter分布式测试：多台机器作为负载机，一起向Tomcat发请求，避免单台机器的CPU、网络资源耗尽。

内容的提问来源于stack exchange，提问作者lexieis18