如何使用 Apache Jmeter 性能测试模拟生产 Spring Boot REST API 的流量 (TPS 9.05)？
How to mimic traffic (TPS 9.05) of production Spring Boot REST API using Apache Jmeter performance testing?
我有一个 API（Spring Boot/Spring 使用 Swagger 的 Web）吞吐量（TPS？）为 9.05（不确定这是如何计算的，但它显示在某些指标页面上）。 API 每小时被点击数千次，有时达到 9,000 次调用的峰值。平均响应时间大约在 ~2000-3000 毫秒之间。这是一个简单的 API，它接受 POST 请求，然后查询 Postgres 数据库和 returns 此数据作为对客户端的 HTTP 响应。此 API 通过 Docker 和 运行 在 AWS (m5.large2) 实例上的 ECS 集群上容器化。
Instance Size vCPU Memory(GiB) Instance Storage(GiB) Network Bandwidth(Gbps) EBS Bandwidth (Mbps)
m5a.2xlarge 8 32 EBS-Only Up to 10 Up to 2,880
我安装了 apache Jmeter，我正在尝试模仿对较低环境的生产 API 调用，以便我可以微调我们 Docker 容器的一些 CPU 和内存配置运行 在 AWS 弹性容器服务 (ECS) 中。
我目前是 运行 5 个线程，1 秒加速，900 秒持续时间 -
是否有系统的方法可以在较低的环境中复制流量负载，以便我可以重现 PROD 负载，从而正确地微调 CPU 和内存？
根据 Performance Testing in Scaled Down Environments. Part One: The Challenges 文章：
An application’s underlying infrastructure is constructed of many different components such as caches, web servers, application servers and disks(I/O). Bandwidth and CDNs also play a role in its function and therefore have to be taken into consideration during scaling. Each component behaves differently in the application according to how it was configured and scaled. However, the tiered structure makes it difficult to calculate how each should be tested and scaled.
Furthermore, there are two ways to scale the application. Scaling-up adds supplementary resources, like CPUs and memory, to a single computer. Scaling-out clusters additional computers together as one system to generate combined computing power. All of these options make it almost impossible to estimate actual data from performance testing in a smaller environment.
因此，与类生产环境相比，没有外推“低级环境”行为的公式，我想说你能做的事情非常有限，例如：
- 运行一个Soak Test, this way you will be able to determine memory leaks
- 运行 启用 profiler tool telemetry 的测试并检查最长的 运行 函数、最大的对象、垃圾收集 activity 等
- 监控 database slow queries 并检查他们的查询计划以在高 cardinality/cost
的情况下进行优化
我有一个 API（Spring Boot/Spring 使用 Swagger 的 Web）吞吐量（TPS？）为 9.05（不确定这是如何计算的，但它显示在某些指标页面上）。 API 每小时被点击数千次，有时达到 9,000 次调用的峰值。平均响应时间大约在 ~2000-3000 毫秒之间。这是一个简单的 API，它接受 POST 请求，然后查询 Postgres 数据库和 returns 此数据作为对客户端的 HTTP 响应。此 API 通过 Docker 和 运行 在 AWS (m5.large2) 实例上的 ECS 集群上容器化。
Instance Size vCPU Memory(GiB) Instance Storage(GiB) Network Bandwidth(Gbps) EBS Bandwidth (Mbps)
m5a.2xlarge 8 32 EBS-Only Up to 10 Up to 2,880
我安装了 apache Jmeter，我正在尝试模仿对较低环境的生产 API 调用，以便我可以微调我们 Docker 容器的一些 CPU 和内存配置运行 在 AWS 弹性容器服务 (ECS) 中。
我目前是 运行 5 个线程，1 秒加速，900 秒持续时间 -
是否有系统的方法可以在较低的环境中复制流量负载，以便我可以重现 PROD 负载，从而正确地微调 CPU 和内存？
根据 Performance Testing in Scaled Down Environments. Part One: The Challenges 文章：
An application’s underlying infrastructure is constructed of many different components such as caches, web servers, application servers and disks(I/O). Bandwidth and CDNs also play a role in its function and therefore have to be taken into consideration during scaling. Each component behaves differently in the application according to how it was configured and scaled. However, the tiered structure makes it difficult to calculate how each should be tested and scaled.
Furthermore, there are two ways to scale the application. Scaling-up adds supplementary resources, like CPUs and memory, to a single computer. Scaling-out clusters additional computers together as one system to generate combined computing power. All of these options make it almost impossible to estimate actual data from performance testing in a smaller environment.
因此，与类生产环境相比，没有外推“低级环境”行为的公式，我想说你能做的事情非常有限，例如：
- 运行一个Soak Test, this way you will be able to determine memory leaks
- 运行 启用 profiler tool telemetry 的测试并检查最长的 运行 函数、最大的对象、垃圾收集 activity 等
- 监控 database slow queries 并检查他们的查询计划以在高 cardinality/cost 的情况下进行优化