我应该什么时候在 AWS 中使用 t2.medium 和 m3.medium 实例类型？答案

【问题标题】：When should I use a t2.medium vs. a m3.medium instance type within AWS?我应该什么时候在 AWS 中使用 t2.medium 和 m3.medium 实例类型？
【发布时间】：2024-05-21 18:15:02
【问题描述】：

它们在性能方面似乎大致相同。

型号 vCPU 内存 (GiB) SSD 存储 (GB) m3.medium 1 3.75 1 x 4

模型 vCPU CPU 积分/小时 Mem (GiB) 存储 t2.medium 2 24 4 仅 EBS

t2.medium 允许突发性能，而 m3.medium 不允许。 t2.medium 甚至比 m3.medium 拥有更多的 vCPU（1 对 2）和内存（3.75 对 4）。唯一的性能提升是带有 m3.medium 的 SSD，我认为如果我执行繁重的 I/O，它可能会很重要。

这是我选择 m3.medium 而不是 t2.medium 的唯一情况吗？

我想运行一个每月获得 20-30k 次点击的网络服务器，所以我怀疑两者都可以满足我的需求，但是更好的选择是什么？

【问题讨论】：

我认为您可能误解了 t2 的可爆发性 - 只有在（平均）使用率低于 40% 时，您才能获得该实例的峰值性能
@FrederickCheung 如果他们每 90 秒可以在单个访问者的情况下连续产生 20% 的 CPU 负载，那么他们需要认真看待他们的代码。

标签： amazon-web-services aws-rds

【解决方案1】：

平均每月 30000 次点击是每 90 秒访问一次。 除非您的网站非常不典型，否则服务器上的负载可能会非常小。 Bursting 将处理多达数百（或数千，经过一些优化）访问者的高峰。

通过适当的缓存，与 t2.micro 规格相当的 VPS 服务器可以使用30000 hits PER MINUTE. 为 Wordpress 博客提供服务. A t2.medium is roughly 4x as powerful 在所有方面都是微型的，m3.medium 具有相似的 RAM 和带宽，但峰值 CPU 较少。

当然，实例存储将比 m3.medium 上的大型 EBS GP2 (SSD) 卷快几倍。 t2 和 c3 中型实例都将具有大约 300-400 Mbit/s 的网络带宽，t2.micro 获得约 60-70 Mbit。 One benchmark 表明，突发模式下的 t2.medium 实际上胜过 c3.large（更不用说 m3.medium，在 3 ECU 对 7 ECU 时，它的功能还不到一半）。

但如前所述，您可能可以通过使用不如您的任何建议强大的东西来节省资金，并且仍然具有出色的性能。

如果您不需要完全配置服务器的能力，共享主机或平台即服务解决方案会更容易。我推荐 OpenShift，因为他们明确建议使用单个小齿轮每月最多 5 万次点击。您可以免费获得其中的 3 个。

如果您确实需要配置服务器，您实际上只需要足够的内存来运行您的服务器和/或数据库。 t2.nano 有 512 MB，t2.micro 有 1 GB。真正的性能瓶颈可能是磁盘 I/O 和网络带宽。第一个可以通过更大的通用 SSD 卷（更多 IOPS）来改进，第二个可以通过使用多个实例和一个 ELB。

确保您在 S3 中托管所有静态资产并充分利用缓存，即使是较小的 AWS 实例也可以每秒处理数百个请求。

基本上：“不用担心，用最便宜、最简单的东西来运行它。”

【讨论】：

这是一个很好的答案。我不知道为什么在这里投反对票，但你有我的 +1。
@EmersonRochaLuiz 谢谢！有人可能不希望听到这是巨大的矫枉过正（或者如果无法处理该流量级别的网站，他们需要处理他们的代码/配置）。
通过适当的缓存，与 t2.micro 规格相当的 VPS 服务器可以为 Wordpress 博客提供每分钟 30000 次点击的服务。 ..什么？？？

【解决方案2】：

虽然 T2.medium 实例和 M3.medium 实例的“硬件”规格看起来相似，但区别在于您考虑 Burstable 与 Fixed Performance 的区别。请参阅 Amazon Web Services 的此链接：

http://aws.amazon.com/ec2/faqs/#burst

以下引用来自该链接：

问：什么时候应该选择突发性能实例，例如 T2？

非常适合突发性能实例（例如 Web 服务器、开发人员环境和小型数据库）的工作负载不会经常或持续使用完整的 CPU，但偶尔需要突发。如果您的应用程序需要持续的高 CPU 性能，我们推荐使用我们的固定性能实例，例如 M3、C3 和 R3。

T2 实例会累积 CPU 积分，但前提是它运行。如果停止或终止，则累积的积分将消失。

页面下方有一条关于 T2 实例的 CPU 积分的重要信息：

问：如果我的 T2 实例的积分不足（CPU 积分余额接近于零），CPU 性能会怎样？

如果您的 T2 实例的 CPU 积分余额为零，则性能将保持在基准 CPU 性能。例如，t2.micro 提供的基准 CPU 性能是物理 CPU 内核的 10%。如果您的实例的 CPU 积分余额接近于零，则 CPU 性能将在 15 分钟内降至基准性能。

这意味着，如果您的可突增积分用完，您的性能将被限制在单个核心的固定百分比内，直到您累积更多； T2.micro 为 10%，T2.small 为 20%，T2.medium 为 40%。

OP 提到的另一个重要区别是 M3.medium 实例可以配置 4GB 的临时存储，其 I/O 容量比持久的弹性块存储 (EBS) 大得多。 T2 实例没有此选项。

最后，这取决于“命中”是什么。在我看来，如果点击意味着一些小于 64k 的静态页面下载或小的动态页面，那么我会探索 T2 选项。对于更长的会话、更多的数据流量或更多的并发用户，我会考虑 M3。如果长时间的性能是一个关键问题，我认为你肯定是在 M3 领域。

查看您当前站点或与您正在设置的站点类似的站点的日志，并确定您所处的情况。

【讨论】：

【解决方案3】：

对您的应用程序进行基准测试并确定最适合您的方案。只有这样才能确定。 “更好的选择”取决于您的应用程序的运行方式和成本要求。

或者，您可以根据成本或其他标准简单地选择一种，如果不足或过于充足，则将实例类型更改为另一种。

【讨论】：

这个。基本上，“这取决于，对其进行基准测试”。或者在 ELB 中运行它们。或者从 t2 开始，如果您没有用完 CPU 积分，请保留它。