如何在亚马逊EC2 T2.micro实例上提高每秒请求数？

Question

我最近启用了一个亚马逊EC2实例，型号为T2.micro。在安装Wildfly 8.2.0Final后，我尝试对Web服务器进行负载测试。我测试了一下服务器，以提供小于500字节大小的静态页面和写入和读取mysql的动态页面。令我惊讶的是，两个测试都得到了类似的结果，大约1000 RPS。我使用top -d 1监视系统，CPU还没有达到最大值，并且有可用内存。我认为EC2可能存在并发连接限制，或者我的设置需要改进。

我的设置是CentOS 7，WileFly/Jboss 8.2.0 Final，MariaDb 5.5。测试工具是分布式模式或命令行模式下的jmeter。测试在远程、同一子网上和本地主机上进行。结果相同。

请帮忙确定瓶颈在哪里。亚马逊EC2实例是否有任何限制可能会影响这一点？谢谢。

- khtwo

---

请注意，如果您在一定时间内以满负载运行T2实例，则它们的CPU将被限制。由于这种不可预测性，我 不建议 将其用于任何类型的负载或压力测试。更多信息请参阅 - http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html - Ragnar

谢谢。非常有用的信息。我理解T2适用于偶尔有高峰访问量的小型网站。根据链接提供的信息，每天一个T2.micro可以拥有大约2小时的完全CPU访问时间，这还不错。之后，10％的限制应该对小型网站可行。 我认为负载测试仍然有效。如果您知道其最大能力，则可以大致了解10％的功率，这可以考虑小型网站。 - khtwo

除了T2上的CPU限制和网络带宽之外，还有其他限制吗？因为提供静态页面并不需要太多的CPU功率。 - khtwo

Answer 1

是的，根据EC2实例类型，有一些限制，其中之一是网络性能。

亚马逊没有发布每种实例类型的确切限制，但在实例类型矩阵中，您可以看到t2.micro具有低到中等的网络性能。如果您需要更好的网络性能，可以在AWS实例类型页面上查看哪些实例具有增强的网络功能：

增强型网络

增强型网络可显著提高每秒数据包 (PPS) 性能，降低网络抖动和延迟。此功能使用新的网络虚拟化堆栈，与传统实现相比，提供更高的 I/O 性能和更低的 CPU 利用率。要利用增强型网络，您应该在 VPC 中启动 HVM AMI，并安装适当的驱动程序。增强型网络目前支持 C4、C3、R3、I2、M4 和 D2 实例。有关如何在 EC2 实例上启用增强型网络的说明，请参阅 Linux 上的增强型网络和 Windows 上的增强型网络教程。要了解更多信息，请查看增强型网络 FAQ 部分。

• Amazon EC2 的带宽限制
• 有人知道不同 EC2 实例的可用带宽吗？
• EC2 实例类型的确切网络性能？

- dgil

---

非常有用的信息。+1。我认为我仍需要时间去深入挖掘，看看里面有什么。您有任何关于如何提高T2.micro实例上RPS的建议吗？而不是更改实例类型。 - khtwo

不，我不知道任何改进它的方法，除了更换更大的实例。 - dgil

这是一个扎实的通用回答; 在这种情况下，我已经在t2.micro实例上进行了实际基准测试。我已经看到优化后的服务器在同一VPC和区域的实例之间推出了> 95 MB / s（使用大请求），并且每秒处理数千个小请求（取决于连接重用）。我知道：我也感到惊讶。在此处，连接管理设置对服务器和客户端都产生巨大影响。 - BobMcGee

Answer 2

您说的没错，对于使用Undertow服务器的Wildfly而言，每秒1000个请求的性能确实太低。Undertow是Java领域中最快且排名前十的服务器之一（参考链接）。 优化起点： 请确保您没有开启请求日志记录（这可能会导致I/O瓶颈），使用最新稳定版JVM版本，并且使用您的应用程序兼容的最新版本的Wildfly。

完成上述步骤后，几乎可以肯定造成瓶颈的是连接创建而不是AWS实例。这可能出现在JMeter或Wildfly子系统中。

为了排除JMeter的问题，请尝试以相同并发级别使用ApacheBenchmark（“ab”），然后使用-k选项运行它以允许连接重用。

• 如果第一个ApacheBenchmark数字远高于JMeter，则问题在于JMeter使用的基于线程的网络模型（可能需要使用其他负载测试工具，例如gatling或locust.io）。
• 如果第二个数字远高于第一个数字，则已证明瓶颈是连接创建。这可以通过调整Undertow服务器设置来解决。

至于WildFly，我需要查看config.xml文件，但是您可以通过调整Undertow子系统设置来提高性能。默认值通常很好，但您需要非常低的I/O线程数量（仅1或CPU数量）。

我看到一个简单的Wildfly 10应用程序在t2.micro实例上远远超过了您的性能表现。

---

基准测试结果，使用Wildfly 10 + docker + Java 8：

服务器设置（位于美国东部1个不同的AZ中，运行最新版亚马逊Linux的EC2 t2.micro）

sudo yum install docker
sudo service docker start
sudo docker run --rm -it -p 8080:8080 svanoort/jboss-demo-app:0.7-lomem

客户端（另一台t2.micro，负载很小，位于不同的可用区）：

ab -c 16 -k -n 1000 http://$SERVER_PRIVATE_IP:8080/rest/cached/500

使用keep-alive，同时有16个并发连接，提供500字节的缓存随机预生成数据。

多次运行的结果：

每秒430个请求（RPS），1171 RPS，1527 RPS，1686 RPS，1977 RPS，2471 RPS，3339 RPS，最终峰值达到 ~6500 RPS，经过数十万个请求后才达到此值。

注意这个值是如何随时间增加而上升的。在进行基准测试之前，预热服务器非常重要，以允许创建足够的处理线程，并允许JIT编译。一般来说，10000个请求是一个很好的起点。

如果我关闭keepalive连接？并发16时峰值约为1450 RPS。 但是请等一下！使用单个线程（并发1）时，只有约340-350 RPS。将并发度增加到16以上并不能提高性能，它保持相当稳定（即使增加到512个并发连接）。

如果我将请求数据大小增加到2000字节，可以通过http://$SERVER_PRIVATE_IP:8080/rest/cached/2000实现，仍然可以达到1367 RPS，显示几乎所有时间都花费在连接处理上。

使用非常大的请求（300k）和keep-alive连接，在主机之间达到约50 MB/s的速度，但在最佳情况下，我曾经见过高达90 MB/s的速度。

对于JBoss/Wildfly来说，这是非常令人印象深刻的性能。请注意，如果主机之间存在更多的延迟，则可能需要更高的并发度，以允许往返时间对连接创建的影响。

- BobMcGee