我读了 EC2 的文档：实例类型 http://aws.amazon.com/ec2/instance-types/, pricing http://aws.amazon.com/ec2/pricing/, FAQ http://aws.amazon.com/ec2/faqs/, 爆发性能 http://aws.amazon.com/ec2/instance-types/#burst并且this http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html#t2-instances-cpu-credits关于CPU积分。
我什至询问了以下AWS支持，但答案并不明确。
事实是，根据文档（虽然不太清楚）和 AWS 支持，所有 3 种实例类型在突发时具有相同的性能，即某种类型的 CPU 核心 100% 使用率。
这就是我的思考过程。假设 t2.micro 的 RAM 足够，并且软件可以水平扩展。拥有 2 个 t2.micro 与 1 个 t2.small 的成本相同，假设负载在它们之间平均分配（可能通过 AWS LB），它们将使用相同数量的总 CPU 并消耗相同数量的 CPU 积分。如果他们的表现回到基准水平，情况也是一样的。
但是，虽然它们正在爆发，但 2 t2.micro 可以实现 t2.small 性能的两倍（同样，成本相同）。相同的概念适用于 t2.medium。此外，使用较小的实例可以实现更严格的自动（或手动）扩展，从而节省资金。
所以我的问题是，鉴于 RAM 和水平缩放不是问题，为什么要使用 t2.micro 以外的其他产品。
编辑：经过一些回复后，这里有一些关于它们的注释：
- 我询问了 AWS 支持，据说 t2.medium 的每个 vCPU 都可以实现 50% 的“全核”。这意味着我所说的同样适用于 t2.medium（如果他们所说的是正确的）。
- T2.micro 实例可用于生产。根据技术和实施情况，单个实例可以处理超过 400 RPS。我也这样，我也这样this guy http://hipsterdevblog.com/blog/2014/12/19/how-far-can-you-go-with-haproxy-and-a-t2-dot-micro/.
- 它们确实需要仔细观察以确保积分不会降低，但我不认为这是不使用它们的理由。
看来你的分析是正确的。
虽然处理器类型没有明确记录，但我通常会看到我的 t2.micro 实例配备一个 Intel Xeon E5-2670 v2 (Ivy Bridge) 核心，而我的 t2.medium 实例则配备两个核心。
只要还有合理数量的剩余 CPU 积分，微型计算机和小型计算机确实应该具有相同的突发性能。我说“一个合理的数字”是因为据记录，性能在 15 分钟窗口内缓慢下降，而不是像 t1.micro 那样急剧下降。
当你升级时，关于这三个类别的所有内容（除了核心，微型还是小型）都会乘以二：基线、每小时获得的学分和学分上限。可以说，就短期突发性能（具有两个核心）而言，该介质非常接近于两个小型处理器，但话又说回来，正如您所指出的，这也正是两个微型处理器所具有的功能。如果内存不是问题，并且流量适当突发，那么您的分析是明智的。
虽然 t1 类几乎完全不适合生产环境，但 t2 类却并非如此。他们是天壤之别。
如果您的代码对于内存来说是紧凑且高效的，并且您的工作负载适合基于 CPU 信用的模型，那么我同意您对 t2.micro 所代表的卓越价值的分析。
当然，这是一个巨大的“如果”。然而，我的网络中有一些系统完全适合这个模型——它们的内存几乎完全在启动时分配，它们的负载相对较轻，但在一天的过程中变化很大。只要你的信用余额没有耗尽，我认为这种方法没有什么问题。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
