Tomcat性能测试实战：JMeter与Gatling工具选型、调优与结果分析指南

1. 项目概述：为什么需要这份终极指南？

在任何一个后端服务上线前，性能测试都是绕不开的一环。尤其是当你把应用部署在Tomcat这样的Web容器上时，它的表现直接决定了用户体验和系统稳定性。我见过太多项目，开发阶段一切顺利，一到上线压测就原形毕露：响应时间飙升、吞吐量上不去、甚至直接宕机。问题出在哪？很多时候不是代码逻辑，而是对Tomcat这个“容器”的性能特性缺乏了解，以及测试工具和方法选得不对。

网上关于性能测试的资料很多，但要么是纯理论的“性能指标科普”，要么是单一工具的“Hello World”式教程。对于一个真正要上线的系统，你需要的是从环境准备、工具选型、场景设计到结果分析的完整闭环，更需要知道不同工具在真实压测中的表现差异。这就是我写这篇指南的初衷：不止于“会用”，更要“用好”。我将以Tomcat为靶子，用业界最主流的两款性能测试工具——JMeter和Gatling，进行一次从理论到实战的深度对比分析。无论你是刚接触性能测试的开发者，还是正在为选型纠结的测试工程师，这篇指南都能给你提供可直接落地的方案和避坑经验。

2. 核心工具选型：JMeter与Gatling的定位与抉择

在开始实战之前，我们必须先搞清楚手里这两把“枪”的特性。JMeter和Gatling虽然目标一致，但设计哲学、适用场景和上手成本截然不同。盲目选择，可能会事倍功半。

2.1 JMeter：功能全面的“瑞士军刀”

Apache JMeter是一款纯Java开发的开源工具，历史久、生态广，几乎是性能测试领域的代名词。它的核心优势在于功能全面和易于上手。

为什么JMeter适合大多数场景？首先，它提供了图形化界面（GUI），你不需要写一行代码，通过拖拽组件就能构建复杂的测试场景，比如HTTP请求、数据库查询、消息队列压测等。这对于测试人员或刚开始接触性能测试的开发者非常友好。其次，它的监听器（Listener）非常丰富，能实时生成各种图表，如响应时间、吞吐量、活跃线程数等，结果直观。最后，它的插件生态极其繁荣，你可以通过安装插件来扩展几乎任何你需要的功能，比如分布式压测、Docker集成、更丰富的报告等。

但是，JMeter的“重”也是它的缺点。GUI模式在发起高并发压测时本身会消耗大量资源，影响测试结果的准确性。因此，生产环境压测的正确姿势是：用GUI设计调试脚本，然后用命令行（CLI）模式无头运行。另外，JMeter的测试计划（.jmx文件）本质是XML，当场景非常复杂时，文件会变得臃肿，版本管理不太方便。

注意：很多新手会直接用GUI界面启动大量线程进行压测，这是大忌。GUI本身会消耗大量内存和CPU来渲染图表，导致你测的不是服务器性能，而是自己电脑的性能。务必养成“设计用GUI，执行用CLI”的习惯。

2.2 Gatling：面向开发者的“高性能利器”

Gatling是一款基于Scala、Akka和Netty构建的开源工具。它的设计初衷就是为了高并发和高效率。与JMeter不同，Gatling推崇“代码即配置”（Configuration as Code）。

为什么Gatling更受开发者青睐？第一，性能开销极低。一个Gatling引擎实例可以轻松模拟成千上万的虚拟用户，对压测机资源占用远小于JMeter，这意味着你可以用更少的机器产生更大的压力。第二，脚本可读性强且易于版本管理。Gatling的测试场景是用Scala DSL（领域特定语言）编写的，结构清晰，像写代码一样，可以很好地用Git进行管理、对比和协作。第三，报告精美且信息丰富。Gatling默认生成的HTML报告非常专业，不仅包含所有关键指标图表，还能自动标出问题点，比如响应时间超过阈值的请求。

当然，Gatling的门槛也更高。你需要对Scala语法有基本了解，虽然它的DSL已经足够简单。它没有实时图形化界面，脚本调试更多依赖日志和模拟运行。因此，它更适合由开发人员或具备编码能力的测试人员来主导性能测试工作。

选型决策树：面对一个具体的Tomcat性能测试任务，你可以这样选择：

• 如果你的团队以测试人员为主，追求快速上手和图形化操作，测试场景多为标准的HTTP API或数据库操作，且并发量在单机数千以内，JMeter是稳妥的选择。
• 如果你的团队开发能力强，追求极致的压测效率和资源利用率，测试场景复杂（如涉及WebSocket、自定义协议），或需要模拟上万级别的高并发，Gatling的优势将非常明显。

在我的经验里，两者混用往往是更高效的策略：用JMeter的图形化能力快速完成前期探索性测试和脚本原型设计；当需要大规模、持续集成的正式压测时，将场景迁移或用Gatling重写，纳入CI/CD流水线。

3. 实战环境搭建与Tomcat基准调优

工欲善其事，必先利其器。一个未经调优的Tomcat和一个配置不当的压测环境，得出的任何结论都是没有意义的。这一部分，我们来搭建一个干净的战场。

3.1 压测环境标准化

性能测试的第一原则是：压测机性能必须远高于被测服务。避免出现“乞丐去测试富翁有多少钱”的尴尬局面。

1. 硬件隔离：理想情况下，Tomcat服务（SUT， System Under Test）部署在一台独立的服务器上，JMeter/Gatling压测机部署在另一台（或一组）网络延迟低的服务器上。如果资源有限，至少要用Docker或虚拟机进行隔离，并通过cgroups、cpulimit等工具限制压测工具的资源使用，确保其不会抢占用Tomcat的资源。
2. 网络优化：确保压测机与Tomcat服务器处于同一局域网，避免公网波动影响。检查并关闭压测机的TCP端口复用超时限制（如Linux下的net.ipv4.tcp_tw_recycle，在高版本内核中已废弃，需注意net.ipv4.tcp_tw_reuse的合理设置）。
3. 工具安装：
   • JMeter：官网下载二进制包，解压即可。关键是要配置好JAVA_HOME环境变量，并建议调整jmeter/bin/jmeter（或jmeter.bat）脚本中的JVM参数，特别是堆内存（-Xms和-Xmx）。对于压测机，建议设置-Xms1g -Xmx2g -XX:MaxMetaspaceSize=256m，避免GC影响。
   • Gatling：推荐使用官方提供的ZIP包或通过包管理器（如sdkman）安装。同样需要Java环境。Gatling的目录结构更清晰，主要关注conf目录下的配置文件和user-files/simulations下的脚本目录。

3.2 Tomcat基础性能调优（必做项）

在压测前，对Tomcat进行一些基础的、公认有效的调优，能让我们得到一个更真实的“基线”性能。这里以Tomcat 9为例，修改conf/server.xml。

连接器（Connector）优化：这是影响HTTP性能的核心。找到默认的8080端口Connector配置，通常如下：

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

我们需要对其进行“武装升级”：

<Connector port="8080" protocol="org.apache.coyote.http11.Http11Nio2Protocol" maxThreads="200" // 关键参数：处理请求的最大线程数。不是越大越好，建议= [CPU核心数 * (1 + 平均等待时间/平均处理时间)]。初始可设为200-500。 minSpareThreads="20" // 最小空闲线程数，加速初始响应 acceptCount="100" // 关键参数：当所有处理线程都在忙时，传入连接请求的最大队列长度。超过则拒绝连接。建议与maxThreads在同一量级。 maxConnections="10000" // 服务器在任何给定时间将接受和处理的最大连接数 connectionTimeout="20000" // 连接超时，20秒通常足够 redirectPort="8443" compression="on" // 开启GZIP压缩，对文本数据提升明显 compressionMinSize="1024" // 仅对大于1KB的数据压缩 noCompressionUserAgents="gozilla, traviata" // 某些旧浏览器不压缩 compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/json" // 指定压缩类型 URIEncoding="UTF-8"/>

• 为什么用Http11Nio2Protocol？这是Tomcat 8以后默认的NIO2实现，相比传统的BIO和旧的NIO，它在高并发连接下的性能和可扩展性更好。
• maxThreads与acceptCount的权衡：maxThreads是“工人”数量，acceptCount是“等候区”大小。如果请求到达速率持续超过工人处理能力，等候区会满，新请求直接被拒绝（返回Connection refused）。这是一个重要的保护机制。压测时，你可以通过观察Tomcat监控，逐步调整这两个值，找到最佳平衡点。

JVM内存优化：修改bin/catalina.sh（Linux）或catalina.bat（Windows），设置JAVA_OPTS。

# 在文件开头附近添加 export JAVA_OPTS="-server -Xms2048m -Xmx2048m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -XX:+UseG1GC -XX:+DisableExplicitGC"

• -Xms2048m -Xmx2048m：将堆内存初始值和最大值设为相同，避免运行中动态调整带来的性能波动。
• -XX:+UseG1GC：对于多核处理器和大内存（>4G）的服务器，G1垃圾收集器通常能提供更好的停顿时间预测和吞吐量。这是目前JDK 8+版本的推荐选择。
• -XX:+DisableExplicitGC：禁止代码中调用System.gc()，防止不必要的全局GC停顿。

做完这些基础调优，你的Tomcat就已经不是一个“默认安装版”了，它为承受压力做好了初步准备。接下来，我们就可以用工具来“考验”它了。

4. JMeter实战：构建一个完整的Tomcat压测场景

让我们从一个最常见的场景开始：测试Tomcat上一个简单的REST API接口。假设我们有一个GET /api/hello的接口。我们将用JMeter完成从脚本创建到结果分析的全过程。

4.1 测试计划设计与关键组件解析

打开JMeter GUI，新建一个测试计划。

1. 线程组（Thread Group）：这是所有请求的起点。右键测试计划 -> 添加 -> 线程（用户） -> 线程组。

   • 线程数（Number of Threads）：虚拟用户数。例如，设为100。
   • Ramp-Up Period（seconds）：在多少秒内启动全部线程。设为10，表示JMeter会用10秒时间，平稳地从0个用户增加到100个用户，避免对服务器造成瞬时冲击。
   • 循环次数（Loop Count）：每个线程执行测试计划的次数。勾选“永远”，然后通过调度器或后续的定时器来控制总时长。

2. HTTP请求采样器（HTTP Request Sampler）：右键线程组 -> 添加 -> 取样器 -> HTTP请求。

   • 协议：http或https
   • 服务器名称或IP：你的Tomcat服务器地址，如192.168.1.100
   • 端口号：8080
   • HTTP请求：GET
   • 路径：/api/hello
   • 你可以在这里添加请求头、参数等。

3. 监听器（Listener）：用于收集和查看结果。常用的有：

   • 查看结果树（View Results Tree）：调试神器，但压测时必须禁用！它会记录每个请求和响应的详细信息，消耗巨大内存，仅用于脚本调试阶段。
   • 聚合报告（Aggregate Report）：核心监听器。提供所有请求的统计摘要，包括平均响应时间、中位数、90%百分位、吞吐量（Requests/sec）、错误率等。
   • 用表格查看结果（View Results in Table）：以表格形式展示每个样本的结果，适合小规模测试查看详情。
   • 响应时间图（Response Time Graph）等：生成图表。

4. 定时器（Timer）：用于控制请求发送频率，模拟真实用户思考时间。例如，在线程组下添加一个固定定时器（Constant Timer），设置延迟为100毫秒，意味着每个用户每次请求后会等待100毫秒再发下一个。

5. 断言（Assertion）：验证响应是否正确。例如，添加一个响应断言（Response Assertion），检查响应文本是否包含“Hello”，或者状态码是否为200。

一个基本的测试结构就搭建好了：线程组（定义用户） -> 定时器（定义节奏） -> HTTP请求（定义动作） -> 断言（定义对错） -> 监听器（收集结果）。

4.2 命令行执行与资源监控

脚本在GUI中调试无误后，保存为tomcat_test.jmx。现在切换到命令行进行真实压测。

# 进入JMeter的bin目录 cd /path/to/jmeter/bin # 基本命令，运行5分钟（300秒） ./jmeter -n -t /path/to/tomcat_test.jmx -l result.jtl -e -o ./report # 参数解释： # -n: 非GUI模式 # -t: 指定测试计划文件 # -l: 指定结果日志文件（JTL格式） # -e: 测试结束后生成HTML报告 # -o: 指定HTML报告输出目录（必须为空目录）

执行后，JMeter会在控制台输出实时进度。运行完毕，打开./report目录下的index.html，你会得到一个非常详细的HTML报告。

压测过程中的关键监控：光看JMeter报告不够，你必须同时监控Tomcat服务器和压测机本身的资源。

• Tomcat服务器监控：

  • 使用jconsole或jvisualvm：连接到Tomcat的JVM，实时查看堆内存使用、GC情况、线程状态。重点关注老年代（Old Gen）内存是否持续增长，Full GC频率是否过高。
  • 使用Tomcat自带的管理器：如果启用了manager应用，可以查看会话数、请求处理时间等。
  • 系统命令：在服务器上运行top（看整体CPU、内存）、vmstat 1（看系统瓶颈）、iostat -x 1（看磁盘IO）。对于Tomcat，CPU使用率是核心指标，应关注%us（用户态）和%sy（系统态）的比例。

• 压测机监控：

  • 同样使用top或htop查看JMeter进程的CPU和内存占用。如果JMeter自身CPU接近100%，说明它可能已成为瓶颈，需要分布式压测或换用Gatling。
  • 使用netstat -an | grep ESTABLISHED | wc -l查看压测机建立的连接数，确保没有达到端口数上限（约2.8万）。

4.3 结果分析与瓶颈初步定位

压测结束后，结合JMeter的HTML报告和服务器监控数据进行分析。

1. 看吞吐量（Throughput）：这是系统处理能力的直接体现，单位是Requests/sec。随着并发用户数增加，吞吐量会先上升后达到一个峰值平台。如果并发增加而吞吐量不增反降，说明系统已出现瓶颈。
2. 看响应时间（Response Time）：重点关注90%百分位（90th Percentile）或95%百分位。平均值容易被极端值拉平，而百分位数能告诉你“绝大多数用户的体验”。例如，90%响应时间为200ms，意味着90%的请求在200ms内完成。
3. 看错误率（Error %）：任何非2xx/3xx的HTTP状态码或断言失败都会计入错误。错误率飙升是系统过载或存在Bug的明显信号。
4. 关联资源监控：
   • 如果响应时间增加、吞吐量持平、CPU使用率接近100%，瓶颈很可能在应用代码或Tomcat配置（如maxThreads）。
   • 如果响应时间增加、吞吐量下降、但CPU不高，瓶颈可能在数据库、外部API调用、或磁盘IO。
   • 如果出现大量连接超时或拒绝连接，检查Tomcat的acceptCount是否过小，或操作系统的文件描述符限制。

通过这一轮JMeter测试，你不仅能得到Tomcat当前配置下的性能基线，还能初步定位系统的瓶颈方向。接下来，我们用Gatling重写这个场景，看看有什么不同。

5. Gatling实战：用代码定义高性能压测

切换到Gatling，我们的思维要从“图形化配置”转变为“代码化描述”。这里我们实现一个相同的场景：100个用户，在10秒内启动，持续访问GET /api/hello5分钟。

5.1 Scala DSL脚本编写详解

在Gatling的user-files/simulations目录下，创建一个Scala文件，例如TomcatBasicSimulation.scala。

import io.gatling.core.Predef._ // 导入核心DSL import io.gatling.http.Predef._ // 导入HTTP DSL import scala.concurrent.duration._ // 导入时间单位 class TomcatBasicSimulation extends Simulation { // 每个测试场景都是一个类，继承Simulation // 1. 定义HTTP协议配置 val httpProtocol = http .baseUrl("http://192.168.1.100:8080") // 基础URL .acceptHeader("application/json") // 公共请求头 .userAgentHeader("Gatling Performance Test") // 2. 定义模拟用户的行为（场景） val scn = scenario("Tomcat Basic API Test") // 场景名称 .exec( http("Get Hello API") // 请求名称，会显示在报告里 .get("/api/hello") // HTTP GET方法 .check(status.is(200)) // 断言：状态码为200 .check(substring("Hello").exists) // 断言：响应体包含"Hello" ) .pause(100.milliseconds) // 每个用户请求间隔100毫秒，模拟思考时间 // 3. 注入用户，定义负载模型 setUp( scn.inject( rampUsers(100).during(10.seconds) // 在10秒内逐步启动100个用户 ).protocols(httpProtocol) ).maxDuration(5.minutes) // 设置整个测试的最大持续时间为5分钟 }

这段代码非常清晰，分为三部分：协议配置、场景定义、负载注入。它比JMeter的XML更紧凑，也更利于版本控制。

5.2 运行测试与生成高级报告

运行Gatling测试同样在命令行完成。

# 进入Gatling的bin目录 cd /path/to/gatling/bin # 运行Gatling ./gatling.sh # 交互式选择你要运行的Simulation # 或者使用非交互模式直接指定 ./gatling.sh -s TomcatBasicSimulation -rf ./results

运行结束后，Gatling会在results目录下生成一个时间戳命名的文件夹，里面包含本次测试的HTML报告。打开index.html，你会被其专业性惊艳。

Gatling报告的核心亮点：

1. 全局指标仪表盘：清晰展示总请求数、成功率、平均响应时间、吞吐量。
2. 详细的响应时间分布：以图表和表格形式展示不同百分位（50th, 75th, 95th, 99th）的响应时间，让你一眼看出长尾效应。
3. 活跃用户与请求数时序图：动态展示测试过程中并发用户数和每秒请求数的变化，与注入策略完全吻合。
4. 响应时间时序图：展示整个测试期间响应时间的变化趋势，可以关联到特定时间点系统可能出现的波动。
5. 错误统计：详细列出所有失败的请求及其原因。
6. 自动问题标识：如果响应时间超过某个阈值或错误率过高，报告会用颜色（如橙色、红色）高亮提示。

Gatling的报告更像一份自动生成的“测试分析报告”，省去了你大量整理数据、绘制图表的时间。

5.3 高级场景：模拟复杂用户行为

Gatling的DSL在描述复杂场景时优势更大。比如，我们要模拟用户登录、浏览商品、下单的流程，并且每个用户的行为有一定随机性。

import scala.util.Random class TomcatEcommerceSimulation extends Simulation { val httpProtocol = http.baseUrl("http://192.168.1.100:8080") // 定义一些测试数据（Feeder），可以从CSV文件读取 val userFeeder = Iterator.continually(Map( "username" -> s"user${Random.nextInt(10000)}", "productId" -> Random.nextInt(1000) )) val scn = scenario("E-commerce User Journey") .feed(userFeeder) // 为每个虚拟用户注入随机数据 .exec( http("Home Page") .get("/") ) .pause(1.second, 3.seconds) // 随机暂停1-3秒，更真实 .exec( http("Login Request") .post("/login") .formParam("username", "${username}") // 使用Feeder中的数据 .formParam("password", "testPass123") .check(jsonPath("$.token").saveAs("authToken")) // 从JSON响应中提取token并保存 ) .pause(500.milliseconds) .exec( http("View Product ${productId}") // 请求名也支持动态变量 .get("/products/${productId}") .header("Authorization", "Bearer ${authToken}") // 使用上一步保存的token ) .pause(2.seconds) .doIf("${productId} < 500") { // 条件判断：只有部分商品会下单 exec( http("Create Order") .post("/orders") .header("Authorization", "Bearer ${authToken}") .body(StringBody("""{"productId": ${productId}, "quantity": 1}""")).asJson .check(status.is(201)) ) } setUp( scn.inject( constantUsersPerSec(20).during(2.minutes) // 更复杂的注入模式：每秒恒定增加20个用户，持续2分钟 ).protocols(httpProtocol) ) }

这种用代码描述业务流程的方式，对于开发人员来说非常自然和强大。你可以轻松实现数据驱动、条件逻辑、状态保持（如Session）等复杂测试逻辑。

6. JMeter vs Gatling：全方位对比与选型建议

经过两轮实战，我们对这两个工具有了切身感受。下面从多个维度进行系统性对比，这张表格可以帮你快速决策：

我的实战选型心得：

1. 快速验证与探索期，用JMeter。当你要快速测试一个接口的极限，或者团队对性能测试流程还不熟悉时，JMeter的图形化界面能让你快速上手，看到结果。它的“录制”功能对于测试网页操作也非常方便。
2. 持续集成与高保真压测，用Gatling。当你需要将性能测试作为代码库的一部分，每次代码提交都自动运行；或者需要模拟上万用户的高并发场景时，Gatling是更优选择。它的资源效率和报告质量能极大提升压测的“性价比”和可信度。
3. 不要排斥混合使用。我所在的团队就采用了一种混合模式：由测试工程师用JMeter完成前期的场景设计和脚本录制，然后将核心的业务流用Gatling DSL重写，纳入自动化流水线。这样兼顾了效率和专业性。

7. 性能测试常见问题与深度排查指南

无论用哪个工具，在压测Tomcat时，你几乎一定会遇到下面这些问题。这里我分享一些从无数次“踩坑”中总结出的排查思路。

7.1 连接数相关问题

问题现象：压测中后期，出现大量ConnectTimeoutException或Connection refused错误。

排查思路：

1. 检查Tomcat配置：回顾server.xml中的maxConnections和acceptCount。如果acceptCount队列满了，新的连接会被拒绝。
2. 检查操作系统限制：
   • Linux文件描述符限制：执行ulimit -n查看单个进程可打开的文件数（包括Socket连接）。对于压测，建议调到65535或更高。修改/etc/security/limits.conf文件。
   • TCP端口范围与复用：压测机作为客户端，每个连接需要一个本地端口。检查/proc/sys/net/ipv4/ip_local_port_range（通常是32768-60999）。短时间内大量连接可能导致端口耗尽。优化方案是启用TCPTIME_WAIT复用（net.ipv4.tcp_tw_reuse = 1）并减少TIME_WAIT超时时间（net.ipv4.tcp_fin_timeout = 30），但需谨慎评估对网络稳定性的影响。
3. 检查JMeter/Gatling配置：在JMeter的HTTP请求高级设置中，可以勾选“Use KeepAlive”。对于Gatling，在httpProtocol中配置.disableWarmUp和.shareConnections可以优化连接管理。

7.2 Tomcat线程池耗尽

问题现象：吞吐量达到一个平台后不再上升，Tomcat的CPU使用率并未饱和，但响应时间急剧增加。查看Tomcat状态（如通过manager/status），发现“Max threads”已满，“Current thread count”接近最大值。

根本原因：maxThreads设置过小，或者应用内部存在同步阻塞（如等待数据库响应、调用慢速外部服务），导致线程被长时间占用，无法处理新请求。

解决方案：

1. 适当增加maxThreads：根据公式线程数 = CPU核心数 * (1 + 平均等待时间/平均处理时间)进行估算。对于IO密集型应用（等待时间长），可以设置较大值（如500-800）。但注意，线程切换本身有开销，不是无限大就好。
2. 优化应用代码：这是根本。使用异步Servlet（Servlet 3.0+）、或采用Spring WebFlux等响应式编程模型，将阻塞操作异步化，用少量线程服务大量请求。
3. 分析线程堆栈：使用jstack <pid>命令或jvisualvm抓取Tomcat进程的线程转储，查看大量线程阻塞在哪个方法调用上，从而定位代码热点或资源竞争点。

7.3 内存溢出与GC频繁

问题现象：压测一段时间后，吞吐量骤降，响应时间飙升，服务器可能无响应。监控发现JVM堆内存使用率持续高位，Full GC异常频繁。

排查与解决：

1. 确认内存泄漏：使用jmap -histo:live <pid>查看存活对象 histogram，或者用jvisualvm的堆Dump功能，分析哪个类的实例数量异常多且不被释放。常见嫌疑犯是静态集合类、未关闭的连接（数据库、HTTP客户端）、Session数据过大等。
2. 优化Tomcat Session管理：如果应用使用Session，确保及时失效。对于集群环境，考虑使用外置Session存储（如Redis）替代Tomcat的Session复制。检查context.xml中Manager的配置。
3. 调整JVM参数：
   • 确保-Xms和-Xmx设置相同，避免堆震荡。
   • 根据服务器内存调整堆大小，为系统和其他进程留出空间（通常堆内存不超过物理内存的50%-70%）。
   • 对于G1GC，可以尝试添加-XX:MaxGCPauseMillis=200来设定目标最大GC停顿时间，JVM会努力达成这个目标。
4. 减少对象创建：压测下，任何微小的优化都会被放大。检查代码中是否存在大量临时对象创建，如日志字符串拼接、频繁的集合拷贝等。

7.4 结果解读误区：平均值陷阱

常见误区：只关注平均响应时间（Average）和平均吞吐量。

正确做法：必须关注百分位数（Percentile）和趋势图。

• 百分位数：比如95%响应时间是500ms，意味着95%的用户体验在500ms以内，但最慢的5%用户可能体验极差。这个指标对保障用户体验至关重要。
• 趋势图：观察整个压测过程中响应时间和吞吐量的曲线。是平稳的，还是缓慢上升（可能暗示内存泄漏）？是否有周期性毛刺（可能和GC或定时任务有关）？

一份有价值的性能测试报告，应该包含在不同并发用户数下的吞吐量、错误率、以及各百分位响应时间的对照表，并附上资源监控的截图，这样才能全面评估系统的性能表现和容量边界。

性能测试不是一个一次性的任务，而是一个持续的过程。通过JMeter和Gatling这样的工具，结合系统性的监控和分析，我们才能让Tomcat，以及运行在其上的应用，在面对真实流量时真正做到稳如磐石。工具只是手段，对系统行为的深刻理解和持续优化，才是性能保障的核心。