【问题标题】:Configuring Jetty for high request volume为高请求量配置 Jetty
【发布时间】:2013-01-09 23:13:49
【问题描述】:

在我们的应用程序中,我们需要处理每秒超过 5,000 个请求的请求量。有人告诉我们,在我们的应用程序类型中使用 Jetty 是可行的(我们必须将 JSON-HTTP API 暴露给远程系统,然后远程系统将启动入站请求和与我们的连接)。

我们收到数千个入站 HTTP 连接,每个连接都是持久的,持续大约 30 秒。然后,远程服务器会尽快向我们发出请求,因为我们可以在每个连接上响应它们。 30 秒后连接关闭并打开另一个连接。我们必须在 100 毫秒(包括网络传输时间)内做出响应。

我们的服务器在具有 8GB RAM 的 EC2 中运行,其中 4GB 分配给我们的 Java VM(过去的研究建议您不应将超过一半的可用 RAM 分配给 JVM)。

根据我们在网上阅读的各种提示,我们目前如何初始化 Jetty:

Server server = new Server();
SelectChannelConnector connector = new SelectChannelConnector();
connector.setPort(config.listenPort);
connector.setThreadPool(new QueuedThreadPool(5120));
connector.setMaxIdleTime(600000);
connector.setRequestBufferSize(10000);
server.setConnectors(new Connector[] { connector });
server.setHandler(this);
server.start();

请注意,我们的线程池中最初只有 512 个线程,我们尝试将其增加到 5120,但这并没有明显帮助。

我们发现,使用这种设置,我们很难每秒处理 300 多个请求。我们认为问题不在于我们的处理程序,因为它只是进行一些快速计算,以及 Gson 序列化/反序列化。

当我们在尝试处理此负载时手动执行自己的 HTTP 请求时,我们发现它可能需要几秒钟才能开始响应。

我们使用的是 Jetty 版本 7.0.0.pre5。

对于解决方案或隔离瓶颈的技术的任何建议,我们将不胜感激。

【问题讨论】:

    标签: java performance http jetty


    【解决方案1】:

    首先,Jetty 7.0.0.pre5 非常旧了。 Jetty 9 现已推出,并进行了许多性能优化。

    在以下位置下载 7.x 行的较新版本 https://www.eclipse.org/jetty/previousversions.html

    以下建议记录在

    请务必阅读它们。

    接下来,线程池大小用于处理接受的请求,512 很高。 5120太可笑了。 选择一个大于 50 和小于 500 的数字。

    如果您有基于 Linux 的 EC2 节点,请确保配置网络以在操作系统级别获得最大收益。 (详见上述列表中标题为“High Load”的文档)

    确保您使用的是最新的 JRE/JDK,例如 Oracle Java 1.6u38 或 1.7u10。另外,如果您有 64 位操作系统,请使用 64 位 JRE/JDK。

    将您的接受器计数 SelectChannelConnector.setAcceptors(int) 设置为介于 1 和 (number_of_cpu_cores - 1) 之间的值。

    最后,设置优化的垃圾收集,并打开 GC Logging 以查看您遇到的问题是与码头有关,还是与 Java 的 GC 有关。如果您通过 GC 日志记录看到有大量 GC“停止世界”事件需要花费大量时间,那么您就知道导致性能问题的另一个原因。

    【讨论】:

    • 嗯,有什么理由不去 Jetty 8 或 9?
    • Jetty 7 适用于 Servlet API 2.5,Jetty 8 适用于 Servlet API 3.0,Jetty 9 目前正处于里程碑阶段(尚未正式发布)
    • 好的,我更新到最新的 Jetty 8 版本,为线程池选择了 250 个线程,实现了“高负载”建议,并且我使用的是最近的 OpenJDK 版本“1.7.0_09”。我还将接受器计数设置为 1,因为服务器有 2 个内核。我不确定我应该改变什么:垃圾收集,我还没有机会调查它是否是 GCing,但过度使用内存似乎不太可能。不幸的是,这些东西似乎都没有显着提高性能,但我可以继续调查。 Jetty 是否维护任何我可以查看的内部统计信息?
    • GC 日志记录和配置不是关于过多的内存使用,而是过多的内存清理/高对象计数/坏对象重用等......根据我们的经验,报告的性能问题中有 80% 与许多和/或长时间的 GC 暂停。
    • 仅供参考:Jetty 9 默认连接器 ThreadQueuePool 最小 8 最大 200。
    猜你喜欢
    • 2021-11-05
    • 1970-01-01
    • 2015-10-13
    • 2013-05-12
    • 1970-01-01
    • 1970-01-01
    • 2014-11-19
    • 1970-01-01
    • 2011-12-16
    相关资源
    最近更新 更多