我们正在为托管容器（Kubernetes）上的其中一个API创建一个新的托管服务器，并且我们正在尝试验证其至少可以处理相同数量的流量负载请求。
我们从一种API开始，在该API中，我们需要每分钟至少处理14万个请求，所有端点组合在一起。
为了验证这一点，我创建了一个简单的JMeter测试，如下所示：
-Test Plan
---Thread Group Endpoint1
-----HTTP Request -> a GET request with query params for /path1
---Thread Group Endpoint2
-----HTTP Request -> a GET request with query params for /path2
对于本地测试，我使用以下设置：
线程组Endpoint1和Endpoint2设置为200 threads (users)，ramp-up period of 1s，loop count = forever和duration 60s。
在运行测试时使用Summary Report侦听器，总计约9300 # Samples。
使用这种方法，仅增加线程组的线程（用户）数，直到达到每分钟140k个请求是安全的吗？
注意：我之前只使用过JMeter，所以我知道整个方法可能是错误的，因此，任何建议和正确方法的指导都值得欢迎。
答案 0 :(得分：1)
您的方法可行，只要它代表实际的应用程序使用情况即可。如果它有2个端点，负载均等/均匀分布，则设置就可以了。如果端点更多，并且其中一些端点的使用率高于其他端点，请考虑使用不同的线程组或其他分配机制（例如Throughput Controller
）来相应地定义工作负载。增加线程数也是可以的，但是请考虑逐渐增加负载{strong> ，使increase ramp-up time如此，您的测试就可以：
通过这种方式，您将能够将各种指标与增加的负载相关联，例如增加响应时间，吞吐量，错误数量等。另外，您将能够指出系统达到saturation point /断点时每秒的线程/请求数是多少，并在负载恢复时恢复。
还要确保您正在跟踪JMeter Best Practices，因为每秒2300/2500个请求不是JMeter可以立即支持的，您需要进行一些调整，至少增加分配的JVM Heap size给JMeter。
答案 1 :(得分：0)
使用一台Jmeter机器可能无法达到每分钟140k请求的期望，在这种情况下，您将需要使用分布式负载测试方法。
引用：http://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.html
如果将启动时间保持为1秒，则会导致系统出现尖峰和不切实际的负载，除非预先预热了服务器，否则不会给出正确的结果，应根据实际/估计逐渐增加负载交通模式。