3.7 Tomcat 性能相关配置

3.7 Tomcat 性能相关配置

3.7 Tomcat 性能相关配置

Tomcat 作为一款广泛应用的 Servlet 容器，其性能直接影响着 Web 应用程序的响应速度和吞吐量。合理的性能配置能够最大化 Tomcat 的资源利用率，提升应用程序的整体性能。本章节将深入探讨 Tomcat 中与性能密切相关的配置项，并提供实践指导和代码示例，帮助您优化 Tomcat 服务器以应对不同的应用场景。

3.7.1 Connector 配置：优化连接器性能

Tomcat 的 Connector 组件负责接收客户端的请求，并将请求传递给 Tomcat 引擎进行处理。Connector 的配置直接影响 Tomcat 处理并发连接的能力和响应速度。以下是一些关键的 Connector 配置项，它们位于 Tomcat 安装目录下的 conf/server.xml 文件中 <Service> 标签内的 <Connector> 元素中。

3.7.1.1 线程池配置 (Thread Pool)

Connector 使用线程池来处理接收到的请求。线程池的配置直接决定了 Tomcat 并发处理请求的能力。

• maxThreads: Connector 可以创建处理请求的最大线程数。默认值通常为 200。在高并发场景下，如果请求处理时间较短，可以适当增加此值。但过大的值会消耗系统资源，导致线程上下文切换开销增加，反而降低性能。

• minSpareThreads: Tomcat 启动时创建并保持运行的最小线程数。这些线程处于空闲状态，等待处理新的请求。设置此值可以减少请求到达时创建线程的延迟。

• maxSpareThreads: 线程池中保持空闲状态的最大线程数。如果空闲线程数超过此值，Tomcat 将会回收一部分空闲线程以释放资源。

• threadPriority: 分配给 Connector 线程的优先级。默认值为 NORM_PRIORITY (5)。在资源竞争激烈的环境中，可以适当提高 Connector 线程的优先级，但需要谨慎，避免影响其他重要进程。

• acceptCount: 当所有处理请求的线程都被占用时，Connector 允许等待队列中排队的最大连接数。如果等待队列已满，新的连接请求将被拒绝。在高并发场景下，如果 maxThreads 不足以处理所有请求，可以适当增加 acceptCount 的值，但过大的值可能会导致请求堆积，增加延迟。

• connectionTimeout: 等待客户端完成 TCP 连接握手的超时时间，以及等待客户端发送请求数据的超时时间，单位为毫秒。默认值为 20000 毫秒 (20 秒)。如果网络环境较差或客户端响应较慢，可以适当增加此值。

代码实践 (server.xml - Connector 配置):

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443"
           maxThreads="300"
           minSpareThreads="50"
           maxSpareThreads="100"
           acceptCount="200"
           threadPriority="5"/>
​

内容详解:

上述配置示例中，我们将 maxThreads 增加到 300，允许 Connector 创建最多 300 个线程来处理请求，提升了并发处理能力。minSpareThreads 和 maxSpareThreads 分别设置为 50 和 100，保证了线程池中始终有一定数量的空闲线程，并限制了空闲线程的最大数量，避免资源浪费。 acceptCount 设置为 200，允许等待队列中最多排队 200 个连接。 connectionTimeout 保持默认值 20 秒。

Mermaid 图表 (graph TD - 线程池模型):

图表解释:

• 客户端请求首先到达 Connector。

• Connector 将请求提交给线程池。

• 如果线程池中有空闲线程，请求将被立即分配给线程处理。

• 如果线程池中没有空闲线程，但请求等待队列未满，请求将被放入队列等待。

• 如果线程池中没有空闲线程且请求等待队列已满，新的连接请求将被拒绝。

• 处理请求的线程会将请求传递给 Tomcat 引擎进行后续处理。

3.7.1.2 I/O 模型配置 (I/O Model)

Connector 的 protocol 属性定义了使用的 I/O 模型。 Tomcat 支持多种 I/O 模型，不同的模型在性能和资源消耗方面有所差异。

• HTTP/1.1 (默认): 默认情况下，Tomcat 使用阻塞式 I/O (BIO) 模型。BIO 模型实现简单，但性能相对较低，特别是在高并发场景下，每个连接都需要一个线程处理，资源消耗较大。

• org.apache.coyote.http11.Http11NioProtocol (NIO): 非阻塞 I/O (NIO) 模型。NIO 模型使用少量的线程处理大量的连接，通过事件驱动的方式，提高了并发处理能力和资源利用率。NIO 是推荐在高并发场景下使用的 I/O 模型。

• org.apache.coyote.http11.Http11AprProtocol (APR): APR (Apache Portable Runtime) 模型。APR 模型利用操作系统底层的本地库，提供更高的性能和可扩展性。APR 模型需要安装 APR 本地库，配置相对复杂，但性能通常优于 NIO。

• org.apache.coyote.http11.Http11Nio2Protocol (NIO2): 基于 Java NIO.2 的异步 I/O 模型。NIO2 模型是 NIO 的进一步发展，提供了更强大的异步 I/O 功能，但配置和使用相对复杂，通常适用于需要极高性能和低延迟的场景。

代码实践 (server.xml - Connector Protocol 配置):

<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
           connectionTimeout="20000"
           redirectPort="8443"
           maxThreads="300"
           minSpareThreads="50"
           maxSpareThreads="100"
           acceptCount="200"
           threadPriority="5"/>
​

内容详解:

上述配置示例中，我们将 Connector 的 protocol 属性修改为 org.apache.coyote.http11.Http11NioProtocol，启用了 NIO 模型。相比默认的 BIO 模型，NIO 模型在高并发场景下能够更有效地利用系统资源，提升 Tomcat 的性能。

Mermaid 图表 (graph TD - BIO vs NIO 模型):

图表解释:

• BIO 模型: 每个客户端连接都需要分配一个独立的线程进行处理。当连接数增多时，线程数量也随之增加，导致资源消耗和线程上下文切换开销增大。

• NIO 模型: 使用一个或少量线程（通过 Selector 组件）监听多个客户端连接的事件。当连接上有事件发生（例如，数据到达），Selector 会通知线程进行处理。NIO 模型通过事件驱动的方式，实现了用少量线程处理大量连接，提高了并发处理能力和资源利用率。

选择 I/O 模型的建议:

• 低并发场景: BIO 模型简单易用，资源消耗相对较低，可以满足需求。

• 高并发场景: NIO 模型是更佳的选择，能够提供更高的并发处理能力和资源利用率。

• 追求极致性能: APR 模型在性能方面通常更优，但配置相对复杂。NIO2 模型是未来的发展方向，但目前成熟度和应用广泛度相对较低。

3.7.2 JVM 调优：优化 Java 虚拟机

Tomcat 运行在 Java 虚拟机 (JVM) 之上，JVM 的性能直接影响 Tomcat 的整体性能。合理的 JVM 调优是提升 Tomcat 性能的关键环节。以下是一些重要的 JVM 调优参数，通常通过设置 CATALINA_OPTS 环境变量来传递给 Tomcat 启动脚本。

3.7.2.1 堆内存配置 (Heap Memory)

Java 堆内存 (Heap) 是 JVM 中用于存储对象实例的区域。堆内存的大小直接影响应用程序可以创建的对象数量和垃圾回收 (Garbage Collection, GC) 的频率和效率。

• -Xms: JVM 启动时分配的初始堆内存大小。建议将 -Xms 和 -Xmx 设置为相同的值，避免 JVM 在运行过程中动态调整堆内存大小，减少性能开销。

• -Xmx: JVM 可以使用的最大堆内存大小。堆内存大小需要根据应用程序的内存需求和服务器的物理内存资源进行合理配置。过小的堆内存会导致频繁的 Full GC，影响性能；过大的堆内存会占用过多系统资源，并可能导致 GC 停顿时间过长。

• -Xmn: 年轻代 (Young Generation) 堆内存大小。年轻代用于存放新创建的对象。年轻代的大小会影响 Minor GC 的频率和效率。较大的年轻代可以减少 Minor GC 的频率，但会增加每次 Minor GC 的时间；较小的年轻代会导致 Minor GC 过于频繁。

• -XX:SurvivorRatio: Eden 区和 Survivor 区的大小比例。年轻代分为 Eden 区和两个 Survivor 区 (From 和 To)。对象首先在 Eden 区分配，当 Eden 区满时，触发 Minor GC，将存活对象复制到 Survivor 区。SurvivorRatio 用于设置 Eden 区和 Survivor 区的大小比例，例如 -XX:SurvivorRatio=8 表示 Eden 区占年轻代的 8/10，两个 Survivor 区各占 1/10。

代码实践 (setenv.sh 或 setenv.bat - JVM 内存配置):

Linux/macOS (setenv.sh):

CATALINA_OPTS="-Xms2g -Xmx2g -Xmn512m -XX:SurvivorRatio=8"
​

Windows (setenv.bat):

set CATALINA_OPTS=-Xms2g -Xmx2g -Xmn512m -XX:SurvivorRatio=8
​

内容详解:

上述配置示例中，我们将 JVM 的初始堆内存和最大堆内存都设置为 2GB (-Xms2g -Xmx2g)，年轻代大小设置为 512MB (-Xmn512m)，Eden 区和 Survivor 区的比例设置为 8:1:1 (-XX:SurvivorRatio=8)。这些值需要根据实际应用程序的内存需求和服务器资源进行调整。

内存配置建议:

• 根据应用负载调整: 通过监控 Tomcat 的内存使用情况和 GC 频率，逐步调整堆内存大小，找到最佳配置。

• 避免频繁 Full GC: Full GC 会导致应用程序长时间停顿，严重影响性能。合理配置堆内存和 GC 策略，尽量减少 Full GC 的发生。

• 关注年轻代大小: 年轻代 GC (Minor GC) 的频率对性能影响较大。合理配置年轻代大小，平衡 Minor GC 的频率和效率。

3.7.2.2 垃圾回收器选择 (Garbage Collector)

JVM 提供了多种垃圾回收器 (Garbage Collector, GC)，不同的 GC 算法适用于不同的应用场景。选择合适的 GC 算法可以显著提升 Tomcat 的性能。

• Serial GC (-XX:+UseSerialGC): 单线程 GC，适用于单核 CPU 或内存较小的服务器。Serial GC 在进行垃圾回收时会暂停所有应用程序线程 ("Stop-The-World" 停顿)，停顿时间较长，不适用于对响应时间敏感的应用。

• Parallel GC (-XX:+UseParallelGC 或 -XX:+UseParallelOldGC): 多线程 GC，适用于多核 CPU，可以并行执行 Minor GC 和 Full GC，提高 GC 效率。Parallel GC 仍然会产生 "Stop-The-World" 停顿，但由于是多线程并行执行，停顿时间相对 Serial GC 较短。

• CMS (Concurrent Mark Sweep) GC (-XX:+UseConcMarkSweepGC): 并发标记清除 GC，适用于对响应时间敏感的应用。CMS GC 大部分 GC 过程可以与应用程序线程并发执行，减少 "Stop-The-World" 停顿时间。但 CMS GC 容易产生碎片，且在 GC 过程中仍然会有短暂的停顿。

• G1 (Garbage-First) GC (-XX:+UseG1GC): Garbage-First GC，JDK 7 Update 4 及更高版本引入的新一代 GC 算法。G1 GC 旨在替代 CMS GC，具有更高的性能和可预测的停顿时间。G1 GC 将堆内存划分为多个大小相等的 Region，并跟踪每个 Region 的垃圾回收价值 (Garbage-First)。G1 GC 优先回收垃圾回收价值最高的 Region，从而在有限的时间内尽可能多地回收垃圾。G1 GC 适用于大堆内存、对停顿时间敏感的应用。

代码实践 (setenv.sh 或 setenv.bat - JVM GC 配置):

使用 G1 GC:

Linux/macOS (setenv.sh):

CATALINA_OPTS="-Xms2g -Xmx2g -Xmn512m -XX:SurvivorRatio=8 -XX:+UseG1GC"
​

Windows (setenv.bat):

set CATALINA_OPTS=-Xms2g -Xmx2g -Xmn512m -XX:SurvivorRatio=8 -XX:+UseG1GC
​

内容详解:

上述配置示例中，我们通过 -XX:+UseG1GC 参数启用了 G1 GC。 G1 GC 适用于大多数现代 Web 应用程序，能够提供较好的性能和可预测的停顿时间。

GC 选择建议:

• JDK 版本: JDK 8 及以上版本推荐使用 G1 GC。JDK 7 可以考虑 CMS GC 或 Parallel GC。JDK 6 及以下版本可以考虑 Parallel GC 或 Serial GC。

• 应用场景: 对响应时间敏感的应用，推荐使用 CMS GC 或 G1 GC。对吞吐量要求较高的应用，可以考虑 Parallel GC 或 G1 GC。

• 服务器资源: 单核 CPU 或内存较小的服务器，可以考虑 Serial GC 或 Parallel GC。多核 CPU 和大内存服务器，推荐使用 Parallel GC、CMS GC 或 G1 GC。

3.7.2.3 其他 JVM 调优参数

除了堆内存和 GC 算法，还有一些其他的 JVM 调优参数可以影响 Tomcat 的性能，例如：

• -XX:+DisableExplicitGC: 禁用 System.gc() 的显式 GC 调用。在某些情况下，应用程序可能会频繁调用 System.gc()，导致不必要的 Full GC，影响性能。禁用显式 GC 可以避免这种情况。

• -XX:+UseStringDeduplication: 字符串去重。JDK 8 Update 20 及更高版本引入的特性。启用字符串去重可以减少堆内存中重复字符串的数量，节省内存空间，降低 GC 频率。

• -Djava.awt.headless=true: headless 模式。如果 Tomcat 运行的应用程序不需要图形界面支持，建议启用 headless 模式，可以减少 JVM 加载图形界面相关的类，提高启动速度和运行效率。

代码实践 (setenv.sh 或 setenv.bat - 其他 JVM 参数配置):

Linux/macOS (setenv.sh):

CATALINA_OPTS="-Xms2g -Xmx2g -Xmn512m -XX:SurvivorRatio=8 -XX:+UseG1GC -XX:+DisableExplicitGC -XX:+UseStringDeduplication -Djava.awt.headless=true"
​

Windows (setenv.bat):

set CATALINA_OPTS=-Xms2g -Xmx2g -Xmn512m -XX:SurvivorRatio=8 -XX:+UseG1GC -XX:+DisableExplicitGC -XX:+UseStringDeduplication -Djava.awt.headless=true
​

内容详解:

上述配置示例中，我们添加了 -XX:+DisableExplicitGC、-XX:+UseStringDeduplication 和 -Djava.awt.headless=true 参数，分别禁用了显式 GC 调用，启用了字符串去重，并启用了 headless 模式。

JVM 调优总结:

JVM 调优是一个复杂的过程，需要根据应用程序的特性、负载情况和服务器资源进行综合考虑。建议通过监控 JVM 的运行状态 (例如，使用 JConsole, VisualVM, JProfiler 等工具) 和性能指标 (例如，吞吐量、响应时间、GC 频率和停顿时间)，逐步调整 JVM 参数，找到最佳配置。

3.7.3 Context 配置：优化 Web 应用上下文

Tomcat 的 Context 组件代表一个 Web 应用程序的运行环境。Context 配置可以针对特定的 Web 应用程序进行性能优化。Context 配置通常在 conf/server.xml 文件中的 <Host> 标签内，或者在 conf/Catalina/localhost/ 目录下的 context.xml 文件中进行。

3.7.3.1 会话管理 (Session Management)

Session 管理是 Web 应用程序中常见的性能瓶颈之一。Tomcat 默认使用基于内存的 Session 管理机制。在高并发场景下，大量的 Session 对象会占用内存资源，并增加 GC 压力。

• Session 持久化: 将 Session 数据持久化到磁盘或数据库中，可以减少内存占用，并提高 Session 的可靠性。Tomcat 支持多种 Session 持久化方式，例如 JDBCStore, FileStore, PersistentManager 等。

• Session 集群: 在集群环境中，需要将 Session 数据在集群节点之间共享，保证用户在不同节点之间切换时 Session 不丢失。Tomcat 支持基于 DeltaManager 和 BackupManager 的 Session 集群方案。

• 禁用 Session: 如果应用程序是无状态的，或者不需要使用 Session，可以禁用 Session 管理，减少内存占用和性能开销。可以通过在 context.xml 文件中设置 <Context session="false"> 来禁用 Session。

代码实践 (context.xml - Session 持久化配置 - JDBCStore):

<Context path="/myapp">
    <Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="false" maxIdleSwap="10">
        <Store className="org.apache.catalina.session.JDBCStore"
               driverName="com.mysql.cj.jdbc.Driver"
               connectionURL="jdbc:mysql://localhost:3306/mydb?characterEncoding=UTF-8&serverTimezone=UTC"
               username="username"
               password="password"
               sessionTable="tomcat_sessions" />
    </Manager>
</Context>
​

内容详解:

上述配置示例中，我们为 /myapp 上下文配置了基于 JDBC 的 Session 持久化。PersistentManager 负责 Session 的持久化管理，JDBCStore 指定使用 JDBC 方式将 Session 数据存储到 MySQL 数据库的 tomcat_sessions 表中。

Session 管理建议:

• 根据应用场景选择: 对于需要 Session 持久化的应用，选择合适的持久化方案，例如 JDBCStore, FileStore 或 Redis 等外部缓存。

• 集群环境考虑 Session 集群: 在集群环境中，配置 Session 集群，保证 Session 的一致性和可用性。

• 无状态应用禁用 Session: 对于无状态应用，禁用 Session 管理，减少资源消耗。

3.7.3.2 资源配置 (Resources)

Context 可以配置各种资源，例如数据源 (DataSource), JNDI 资源等。资源的配置和管理也会影响 Tomcat 的性能。

• 连接池配置 (Connection Pooling): 对于数据库连接等资源，使用连接池可以提高资源利用率和性能。Tomcat 内置了 DBCP (Database Connection Pool) 连接池，也可以集成其他连接池，例如 HikariCP, C3P0 等。

• 资源限制 (Resource Limits): 可以限制 Context 可以使用的资源，例如内存、CPU、线程等，防止单个 Web 应用占用过多资源，影响其他应用或 Tomcat 服务器的稳定性。

代码实践 (context.xml - 数据源配置 - DBCP):

<Context path="/myapp">
    <Resource name="jdbc/mydb" auth="Container" type="javax.sql.DataSource"
              driverClassName="com.mysql.cj.jdbc.Driver"
              url="jdbc:mysql://localhost:3306/mydb?characterEncoding=UTF-8&serverTimezone=UTC"
              username="username"
              password="password"
              maxActive="100"
              maxIdle="30"
              maxWait="10000"/>
</Context>
​

内容详解:

上述配置示例中，我们为 /myapp 上下文配置了一个名为 jdbc/mydb 的数据源。使用了 DBCP 连接池，并配置了连接池的最大活动连接数 (maxActive)、最大空闲连接数 (maxIdle) 和最大等待时间 (maxWait) 等参数。

资源配置建议:

• 使用连接池: 对于需要频繁获取和释放的资源，例如数据库连接，务必使用连接池，提高性能。

• 合理配置连接池参数: 根据应用负载和资源需求，合理配置连接池的参数，例如最大连接数、最小空闲连接数、连接超时时间等。

• 监控资源使用情况: 监控 Context 的资源使用情况，例如连接池的连接数、内存使用量等，及时发现和解决资源瓶颈问题。

3.7.4 静态资源优化：提升静态内容访问速度

静态资源 (例如，HTML, CSS, JavaScript, 图片等) 的访问速度直接影响用户体验。Tomcat 提供了多种方式来优化静态资源的访问性能。

3.7.4.1 启用 Gzip 压缩 (Gzip Compression)

启用 Gzip 压缩可以减小静态资源的文件大小，减少网络传输带宽，加快页面加载速度。Tomcat 可以通过配置 Connector 或 Valve 来启用 Gzip 压缩。

代码实践 (server.xml - Connector 配置 Gzip 压缩):

<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
           connectionTimeout="20000"
           redirectPort="8443"
           maxThreads="300"
           minSpareThreads="50"
           maxSpareThreads="100"
           acceptCount="200"
           threadPriority="5"
           compression="on"
           compressionMinSize="2048"
           noCompressionUserAgents="gozilla,traviata,mydog"
           compressableMimeType="text/html,text/xml,text/css,text/javascript,application/javascript"/>
​

内容详解:

上述配置示例中，我们在 Connector 中启用了 Gzip 压缩：

• compression="on": 启用 Gzip 压缩。

• compressionMinSize="2048": 只有文件大小超过 2048 字节的文件才会进行压缩。

• noCompressionUserAgents="gozilla,traviata,mydog": 对于 User-Agent 包含 "gozilla", "traviata", "mydog" 的请求，不进行压缩。

• compressableMimeType="text/html,text/xml,text/css,text/javascript,application/javascript": 指定需要压缩的 MIME 类型。

代码实践 (server.xml - Valve 配置 Gzip 压缩):

<Host name="localhost"  appBase="webapps"
      unpackWARs="true" autoDeploy="true">
    <Valve className="org.apache.catalina.valves.CompressionValve"
           compression="on"
           compressionMinSize="2048"
           noCompressionUserAgents="gozilla,traviata,mydog"
           compressableMimeType="text/html,text/xml,text/css,text/javascript,application/javascript"/>
    </Host>
​

内容详解:

Valve 配置 Gzip 压缩与 Connector 配置类似，只是将配置放在 <Valve> 标签中。Valve 可以更灵活地控制压缩的范围，例如可以针对特定的 Host 或 Context 启用压缩。

3.7.4.2 设置 Expires 头部 (Expires Header)

设置 Expires 头部可以指示浏览器缓存静态资源，减少重复请求，提高页面加载速度。可以通过 Tomcat 的 DefaultServlet 或 Web 应用的过滤器来设置 Expires 头部。