记录一次java web接口压测调优过程

暴力出奇迹

把cpu核数、内存大小、磁盘大小拉满， 64核 512GB 2T硬盘，插入和更新单条sql耗时降低到5ms左右

hikari数据库连接池多大合适

配置Hikari连接池的大小（即最大连接数 maximum-pool-size）时，应该考虑几个关键因素，包括但不限于服务器的硬件规格、应用程序的并发需求、数据库的工作负载特性以及数据库自身的配置。

对于8核心处理器的MySQL服务器，以下是一些通用的指导原则：

1. 硬件资源：CPU核心数是其中一个因素，但更重要的是内存、I/O能力以及网络带宽。高核心数意味着服务器有较高的并发处理能力，但数据库连接的开销也涉及到内存使用和磁盘I/O。

2. 应用程序需求：考虑应用程序的并发用户数和请求模式。如果应用有大量的读操作而写操作较少，连接池可以适当增大；反之，如果写操作较多，由于写操作通常涉及更多的锁竞争和事务管理，可能需要较小的连接池来减少冲突。

3. 数据库配置：MySQL的max_connections参数定义了可以同时打开的最大连接数，这应该是连接池大小的上限。此外，数据库的缓冲和缓存设置也会影响连接池的最佳大小。

4. 连接开销：每个数据库连接都有一定的资源开销，包括内存和上下文切换成本。过多的连接可能导致内存不足和CPU过度调度。

5. 监控和测试：最终的配置应该基于监控和压力测试的结果，以确保既满足性能需求又避免资源浪费。

一种常见的经验公式是将连接池大小设置为 CPU 核心数的2到4倍。例如，对于8核心的服务器，初步可以尝试将 maximum-pool-size 设置在16到32之间。然而，这只是一个起点，实际的最优值需要根据上述因素进行调整。

建议开始时选择一个保守的值，然后根据应用的实际负载进行微调。使用HikariCP的监控功能，如metrics和healthCheckRegistry，可以帮助你了解连接池的使用情况，从而做出更合理的配置决策。在生产环境中，应该持续监控数据库和应用的性能指标，以确保连接池的配置是最优的。

tomcat连接数设置多大合适

以下是一个示例代码片段，演示如何使用Netty创建一个具有特定连接数和线程数限制的服务：

import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioServerSocketChannel;
import io.netty.handler.logging.LogLevel;
import io.netty.handler.logging.LoggingHandler;

public class MaxConnectionsServer {

    private final int port;

    public void run() throws Exception {
        // BossGroup is responsible for accepting new connections. 接收新连接并注册到workerGroup，理论上可接受连接无上限的
        EventLoopGroup bossGroup = new NioEventLoopGroup();
        // WorkerGroup is responsible for handling the traffic of accepted connections. 非阻塞IO轮训，以cpu核心数*2的线程池来轮训事件
        EventLoopGroup workerGroup = new NioEventLoopGroup(maxThreads);

        try {
            ServerBootstrap b = new ServerBootstrap();
            b.group(bossGroup, workerGroup)
             .channel(NioServerSocketChannel.class)
             .handler(new LoggingHandler(LogLevel.INFO))
             .childHandler(new ChannelInitializer<SocketChannel>() {
                 @Override
                 public void initChannel(SocketChannel ch) throws Exception {
                     // Add your own handlers here. 提交请求数据到已创建的处理业务的线程池，如果提交的请求被拒绝（线程池已满）则客户端得不到应答，则客户端抛出socketTimeout异常
                     ch.pipeline().addLast(new YourHandler());
                 }
             });

            // Bind and start to accept incoming connections.
            ChannelFuture f = b.bind(port).sync();

            // Wait until the server socket is closed.
            f.channel().closeFuture().sync();
        } finally {
            // Gracefully close all event loops to terminate all threads.
            bossGroup.shutdownGracefully();
            workerGroup.shutdownGracefully();
        }
    }
}

3台8核服务器，目标400tps

1、server采用的线程数200，队列100，借鉴tomcat

Tomcat作为一款流行的Java Web服务器，其默认配置覆盖了从端口设置、应用部署、日志记录到性能调整等多个方面。以下是一些关键的默认配置概览：

1. 端口配置:

   • 监听端口: Tomcat默认监听8080端口作为HTTP请求的入口。这意味着，如果你在本地安装了Tomcat，可以通过http://localhost:8080来访问它的默认首页。
   • 关闭端口: 默认情况下，Tomcat会在8005端口监听关闭命令。发送SHUTDOWN命令到这个端口可以安全地关闭Tomcat服务器。

2. 默认应用与主页:

   • Tomcat的默认应用目录是webapps/ROOT，当你访问Tomcat的根URL（例如，http://localhost:8080）时，它会显示这个目录下的内容作为默认主页。如果你想更改默认应用，可以直接替换或修改ROOT目录下的内容。

3. 日志配置:

   • 日志的默认配置文件是conf/logging.properties。Tomcat默认将日志输出到catalina.out文件以及控制台。你可以通过修改这个文件来调整日志级别、格式和输出目标。

4. 最大连接数与线程池:

   • Tomcat默认的最大线程数（maxThreads）是200，这意味着最多可以同时处理200个请求。连接等待队列的默认长度是100。这些值可以根据实际需求在server.xml中进行调整。

5. Context配置:

   • context.xml文件提供了所有Web应用共有的默认上下文配置。每个Web应用也可以有自己的META-INF/context.xml来覆盖这些默认设置。

6. 虚拟主机配置:

   • 默认情况下，Tomcat没有配置虚拟主机。如果你需要为不同的域名提供服务，可以在server.xml中的<Host>元素进行配置。

7. 管理应用:

   • Tomcat包含两个内置的管理应用：Manager和Admin Web Application，它们分别允许用户管理和监控部署的Web应用以及进行更高级的配置管理。这些应用需要在conf/tomcat-users.xml中配置相应的用户角色才能访问。

请注意，随着时间的推移和不同版本的更新，Tomcat的具体默认配置可能会有所变化。上述信息基于最近的资料汇总，对于特定版本的Tomcat，建议参考其官方文档或发行说明获取最准确的默认配置详情。

2、数据库连接池用hikari,单机线程池连接数配置16

HikariCP 是一个高性能的 JDBC 连接池，它在 Spring Boot 应用中经常作为默认的数据源。以下是 HikariCP 数据源的一些常用配置参数及其说明：

1. spring.datasource.hikari.maximumPoolSize:

   • 描述：连接池中允许的最大连接数。
   • 默认值：根据系统的环境和数据库的不同而不同，通常为 10。

2. spring.datasource.hikari.minimumIdle:

   • 描述：连接池中维护的最小空闲连接数。
   • 默认值：与 maximumPoolSize 相同。

3. spring.datasource.hikari.connectionTimeout:

   • 描述：等待从连接池获取连接的最长时间（毫秒），超时则抛出异常。
   • 默认值：30000 毫秒（30秒）。

4. spring.datasource.hikari.idleTimeout:

   • 描述：连接允许在池中闲置的最长时间，超时则被释放。
   • 默认值：600000 毫秒（10分钟）。

5. spring.datasource.hikari.maxLifetime:

   • 描述：连接的最大生命周期，超时后连接将被关闭并重新创建。
   • 默认值：1800000 毫秒（30分钟）。

6. spring.datasource.hikari.autoCommit:

   • 描述：从连接池中获取的连接是否默认开启自动提交。
   • 默认值：true。

7. spring.datasource.hikari.poolName:

   • 描述：连接池的名称。
   • 默认值：无，默认生成一个随机的名字。

8. spring.datasource.hikari.dataSourceClassName:

   • 描述：具体数据库的 JDBC 数据源类名。
   • 默认值：无，需要根据使用的数据库驱动进行配置。

9. spring.datasource.hikari.jdbcUrl:

   • 描述：数据库的 JDBC URL。
   • 默认值：无，必须手动配置。

10. spring.datasource.hikari.username:

    • 描述：数据库用户名。
    • 默认值：无，必须手动配置。

11. spring.datasource.hikari.password:

    • 描述：数据库密码。
    • 默认值：无，必须手动配置。

请注意，这些参数的具体默认值可能会随 HikariCP 版本更新而变化，建议参考最新的官方文档或使用 Spring Boot 应用中的默认配置作为指导。在实际应用中，根据业务需求和数据库性能调整这些参数，可以有效提升应用程序的性能。

web连接数：cpu占用率

数据库连接数：压测

hikari About Pool Sizing

jvm内存占用，GC频率

监控gc

jstat -gcutil 是一个命令行工具，用于监控 Java 虚拟机 (JVM) 的垃圾收集 (GC) 状态和堆内存使用情况。它是 Oracle JDK 和 OpenJDK 中的 Jstat 工具的一部分，可以提供有关 JVM 内存管理的实时统计信息。

当你使用 jstat -gcutil 命令时，它会输出以下信息：

• S0U: Survivor Space 0 的使用率（百分比）。
• S1U: Survivor Space 1 的使用率（百分比）。
• EU: Eden Space 的使用率（百分比）。
• OU: Old Gen (Old Space) 的使用率（百分比）。
• MU: Metaspace 的使用率（百分比）。在 Java 8 及更高版本中，Metaspace 替代了永久代 (PermGen)。
• CCSU: Compressed Class Space 的使用率（百分比）。这也是 Java 8 及更高版本中的一部分。
• YGC: 自 JVM 启动以来 Young Generation 的垃圾收集次数。
• YGCT: Young Generation 的垃圾收集总耗时（秒）。
• FGC: Full Garbage Collection（或称为 Old Generation 的垃圾收集）的次数。
• FGCT: Full Garbage Collection 的总耗时（秒）。
• GCT: 总的垃圾收集时间（秒）。

jstat -gcutil 命令的格式如下：

jstat -gcutil <pid> [interval] [count]

• <pid> 是 Java 进程的进程 ID。
• [interval] 是两次输出之间的时间间隔（以毫秒为单位），如果省略则只输出一次。
• [count] 是输出的次数，如果省略则默认为无限次。

例如，要监控 PID 为 1234 的 JVM 的 GC 状态，每秒输出一次，共输出 10 次，可以使用以下命令：

jstat -gcutil 1234 1000 10

这个命令非常适合在诊断内存泄漏、性能瓶颈和优化垃圾收集策略时使用。通过监控这些指标，可以了解 JVM 的内存使用模式，识别潜在问题，并调整 JVM 参数以优化应用性能。

监控cpu

mpstat -P ALL 1 是一个在 Linux 系统中用于监控 CPU 使用情况的命令。这个命令使用 mpstat 工具，它是 sysstat 包的一部分，专门设计用于多处理器系统中获取详细的 CPU 统计信息。让我们分解一下这个命令：

• mpstat：这是命令的名字，它代表 “Multiprocessor Statistics”，用于报告 CPU 的使用情况。

• -P ALL：这个选项指定 mpstat 应该报告所有 CPU 核心（包括多处理器系统中的每一个核心）的详细统计信息。ALL 关键字表示所有 CPU 都会被监控。

• 1：这个数字表示采样间隔，即 mpstat 将每隔 1 秒钟收集和报告一次 CPU 使用数据。这意味着输出将每秒刷新一次，显示最新的 CPU 使用情况。

当你运行 mpstat -P ALL 1 命令时，你将看到类似以下的输出：

Linux 5.4.0-104-generic (yourhostname)       01/01/2023     _x86_64_        (8 CPU)

01:23:45 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
01:23:46 PM  all    1.00    0.00    0.50    0.00    0.00    0.00    0.00    0.00   98.50
01:23:46 PM    0    0.00    0.00    0.50    0.00    0.00    0.00    0.00    0.00  100.00
01:23:46 PM    1    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:23:46 PM    2    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
...

每一列的含义如下：

• %usr：用户空间应用程序消耗的 CPU 时间百分比。
• %nice：高优先级（nice 值较低）进程消耗的 CPU 时间百分比。
• %sys：内核空间消耗的 CPU 时间百分比。
• %iowait：CPU 等待 I/O 完成的时间百分比。
• %irq：处理硬件中断请求的时间百分比。
• %soft：处理软件中断请求的时间百分比。
• %steal：虚拟机管理程序消耗的 CPU 时间百分比（在虚拟化环境中）。
• %guest：虚拟机运行消耗的 CPU 时间百分比。
• %idle：CPU 处于空闲状态的时间百分比。

这个命令对于监控系统性能和诊断 CPU 使用情况的问题非常有用，特别是在多处理器或多核心系统中。