java - 执行负载测试时，1 个或多个 vertx 后端返回相同的 TPS(单个节点或多个节点的 TPS 相同)

Question

我在 Nginx 后面有 4 个 Vertx 模拟 api。当对 250 个用户执行 jmeter 负载测试时，对于 1 个或更多 vertx 节点，结果是相同的。 例如:- 使用 1 个 Vertx 节点(0 秒延迟)- 995 tps，并且使用所有 4 个节点，结果是相同的。如何通过增加后端来提高 tps？ p.s 当我设置一个计时器来创建后端延迟时，tps 显着下降(950--> 180)。这是由于我的代码中的错误吗？

服务器 - Linux 64，Jmeter 实例 3.0，具有 250 个用户/125 次提升

//---Vertx mock service ---------------------------
public class App extends AbstractVerticle {

    private static Logger LOGGER = Logger.getLogger("InfoLogging");
    public static void main(String[] args) {
        Vertx vertx = Vertx.vertx();
 PropertyConfigurator.configure(System.getProperty("user.dir")+"/log4j.properties");

        HttpServer httpServer = vertx.createHttpServer();
        Router router = Router.router(vertx);

            Route ELKPaymentResponse = router
                    .post("/:param/amount")
                    .produces("application/json")
                    .handler(routingContext -> {
                          routingContext.request().bodyHandler(bodyHandler -> {
                        HttpServerResponse response = routingContext.response();
                     //   response.setChunked(true);
                        String JsonResponse ="{  
              //Mock service here
}";

                        vertx.setTimer(TimeUnit.SECONDS.toMillis(1), l -> {
                         JsonObject json = new JsonObject(JsonResponse);
                             response.putHeader("Content-Type", "application/json; charset=UTF8")
                             .setStatusCode(200)
                             .end(Json.encodePrettily(json));
                         });
                          }); 
                   });

Answer 1

在 995 tps 测试期间，JMeter 服务器的资源利用率(CPU、内存、网络、连接、线程等)是多少？在 995 tps 测试期间，单个 Vertx 节点的资源利用率是多少？

确保 JMeter 不是瓶颈。验证单个顶点服务器是否正在无瓶颈地处理流量。 995 TPS 的单个 vertx 服务器资源利用率可以让您了解单个服务器可以处理多少 tps。然后才继续移动到多个顶点。

对于 995 TPS 测试运行来说，250 个线程相当低。我更喜欢使用吞吐量整形计时器之类的东西来设置目标 TPS。我使用大量的 JMeter 线程来确保每个线程的节奏大于响应时间。这样，tps 就不再简单地由响应时间决定。如果没有节奏，你就会失去控制，并且很难管理任何可重复的数字并找到被测系统的瓶颈。