如何增加亚马逊 EC2 T2.micro 实例的每秒请求数？答案

【问题标题】：How to increase the request per second on amazon EC2 T2.micro instance?如何增加亚马逊 EC2 T2.micro 实例的每秒请求数？
【发布时间】：2015-06-17 13:33:02
【问题描述】：

我最近使用了一个 Amazon 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。测试是在远程、同一子网和本地主机上执行的。都得到相同的结果。

请您帮忙确定瓶颈在哪里。 Amazon EC2 实例是否有任何可能影响此的限制？谢谢。

【问题讨论】：

请注意，如果您在一段时间内以完全利用率运行 T2 实例，它们的 CPU 会受到限制。由于这种不可预测性，我不建议将它们用于任何类型的负载或压力测试。更多信息在这里 - docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html
谢谢。非常有用的信息。我知道 T2 是针对小型网站的，偶尔会有高峰访问。根据链接信息，每天，T2.micro 可以有大约 2 小时的完整 CPU 访问时间，还不错。在那之后，10% 的节流对于小型网站应该是可行的。我认为负载测试应该仍然有效。如果你知道它的最大能力，那么你大约可以知道 10% 的能力，这对于小型网站来说可以考虑。
T2上除了CPU节流限制和网络带宽之外，还有其他模仿吗？因为提供静态页面不需要那么多 CPU 资源。

标签： performance amazon-ec2 performance-testing load-testing

【解决方案1】：

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

Amazon 没有公布每种类型实例的确切限制，但在Instance Types Matrix 中您可以看到t2.micro 具有低到中等的网络性能。如果您需要更好的网络性能，您可以查看AWS instance types 页面，该页面显示了哪些实例具有增强的网络：

增强网络

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

您可以在这些 SO 和 SF 问题中获得更多信息：

【讨论】：

非常有用的信息。 +1。我想我还需要时间去挖掘，看看里面有什么。您对改进 T2.micro 实例的 RPS 有什么建议吗？而不是更改实例类型。
不，我不知道有什么办法可以改进它，除非换成更大的实例。
这是一个可靠的一般答案；在这种情况下，我已经对 t2.micro 实例进行了实际基准测试。我已经看到优化的服务器在同一 VPC 和区域中的实例之间推送 > 95 MB/s（有大请求），并且每秒执行数千个小请求（取决于连接重用）。我知道：我也很惊讶。连接管理设置对这里的服务器和客户端都有很大的影响。

【解决方案2】：

你说得对，Wildfly 的 1000 RPS 感觉非常低，因为为其提供动力的 Undertow 服务器是 one of the fastest in Java land 并且在 10 个最快的时期内。

优化的起点： 确保您没有请求登录（这可能会导致 I/O 瓶颈），使用最新的稳定 JVM，并且可能值得使用您的应用程序使用的最新 Wildfly 版本。

完成此操作后，您几乎肯定会遇到连接创建的瓶颈，而不是您的 AWS 实例。这可以在 JMeter 中，也可以在 Wildfly 子系统中。

要消除 JMeter 作为罪魁祸首，请在相同的并发级别尝试 ApacheBenchmark ("ab")，然后使用 -k 选项进行尝试（以允许连接重用）。

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

就 WildFly 而言，我必须查看 config.xml，但您可以通过调整 Undertow subsystem 设置来提高性能。默认值通常是固定的，但您希望 I/O 线程数非常少（1 个或 CPU 数，仅此而已）。

我看到一个微不足道的 Wildfly 10 应用程序远远超过了您在 t2.micro 实例上看到的性能。

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

服务器设置（EC2 t2.micro 运行最新的 amazon linux，位于 US-east-1，不同的可用区）

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，最小负载，不同 AZ）：

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

16 个保持连接的并发连接，提供 500 字节的缓存随机预生成数据

多次运行的结果：每秒 430 个请求 (RPS)、1171 RPS、1527 RPS、1686 RPS、1977 RPS、2471 RPS、3339 RPS，最终在数十万个请求后达到 ~6500 RPS 的峰值。

注意到随着时间的推移它是如何上升的吗？在进行基准测试之前预热服务器很重要，以允许创建足够的处理程序线程并允许 JIT 编译。 10,000 个请求是一个很好的起点。

如果我关闭连接保持连接？峰值约为 1450 RPS，并发 16。 但等等！使用单个线程（并发 1），它仅提供 ~340-350 RPS。将并发数增加到 16 以上并不会带来更高的性能，它仍然相当稳定（甚至高达 512 个并发连接）。

如果我通过使用 http://$SERVER_PRIVATE_IP:8080/rest/cached/2000 将请求数据大小增加到 2000 字节，那么它仍然达到 1367 RPS，表明几乎所有时间都花在了连接处理上。

对于非常大的 (300k) 请求和保持连接，我在主机之间达到了大约 50 MB/s，但在最佳情况下我看到了高达 90 MB/s。

我想说，JBoss/Wildfly 的表现令人印象深刻。请注意，如果主机之间存在更多延迟，则可能需要更高的并发性，以考虑往返时间对连接创建的影响。

【讨论】：