问题描述
我阅读了EC2的文档：，，，以及有关CPU信用。
我什至问了以下AWS支持，答案还不清楚。
I read EC2's docs: instance types, pricing, FAQ, burstable performance and also this about CPU credits.I even asked the following AWS support and the answer wasn't clear.
事实是，根据文档（尽管不太清楚）和AWS支持，所有3种实例类型在爆发时都具有相同的性能，这是某种类型的CPU内核的100％使用率。
The thing is, according to the docs (although not too clear) and AWS support, all 3 instance types have the same performance while bursting, it's 100% usage of a certain type of CPU core.
所以这是我的思考过程。假设t2.micro的RAM足够，并且该软件可以水平扩展。拥有2 t2.micro的成本与1 t2.small的成本相同，假设负载在它们之间平均分配（可能通过AWS LB），则它们将使用相同数量的总CPU，并消耗相同数量的CPU信用。如果它们恢复到基准性能，那将是相同的。
So this is my thought process. Assuming t2.micro's RAM is enough and that the software can scale horizontally. Having 2 t2.micro has the same cost as 1 t2.small, assuming the load distributed equally between them (probably via AWS LB) they will use the same amount of total CPU and consume the same amount of CPU credits. If they were to fall back to baseline performance, it would be the same.
但是，当它们爆裂时，2 t2.micro可以达到2 t2的性能。 .small（同样，费用相同）。相同的概念适用于t2.medium。同样，使用较小的实例还可以进行自动（或手动）缩放，从而节省资金。
BUT, while they are bursting, 2 t2.micro can achieve x2 the performance of a t2.small (again, for the same cost). Same concept applies to t2.medium. Also using smaller instances allows for tigther auto (or manual) scaling which allows one to save money.
所以我的问题是，考虑到RAM和水平缩放不是问题，
So my question is, given RAM and horizontal scale is not a problem, why would one use other than t2.micro.
编辑：经过一番回复，以下是关于它们的一些说明：
After some replies, here are a few notes about them:
- 我询问了AWS支持问题，据推测，t2.medium的每个vCPU可以达到全核心的50％。这意味着我说过的同样适用于t2.medium（如果他们说的是正确的话）。
- T2.micro实例可以用于生产。根据技术和实现，单个实例可以处理超过400 RPS。我可以，。
- 他们确实需要仔细检查以确保学分不会降低，但我不接受将其作为不使用的理由
推荐答案
您的分析似乎正确。
虽然没有明确记录处理器类型，但我通常会看到我的t2.micro实例配备一个Intel Xeon E5-2670 v2（Ivy Bridge）内核，而我的t2.medium实例具有两个。
While the processor type isn't clearly documented, I typically see my t2.micro instances equipped with one Intel Xeon E5-2670 v2 (Ivy Bridge) core, and my t2.medium instances have two of them.
只要有足够数量的CPU积分，微型和小型就应该具有相同的突发性能。我之所以说一个合理的数字，是因为据记载，性能在15分钟的窗口内会正常下降，而不是像t1.micro那样急剧下降。
The micro and small should indeed have the same burst performance for as long as they have a reasonable number of CPU credits remaining. I say "a reasonable number" because the performance is documented to degrade gracefully over a 15 minute window, rather than dropping off sharply like the t1.micro does.
当您升职时，这三个类别（核心类别（微型和小型）除外）乘以2：基准线，每小时获得的信用和信用额度。可以说，就短期突发性能（具有两个核心）而言，该介质非常类似于两个较小的介质，但同样，正如您所指出的，这也正是您拥有两个micros的能力。如果不关心内存，并且流量适当突发，则您的分析是明智的。
Everything about the three classes (except the core, in micro vs small) multiplies by two as you step up: baseline, credits earned per hour, and credit cap. Arguably, the medium is very closely equivalent to two smalls when it comes to short term burst performance (with its two cores) but then again, that's also exactly the capability that you have with two micros, as you point out. If memory is not a concern, and traffic is appropriately bursty, your analysis is sensible.
虽然t1类几乎完全不适合生产环境，但同样的事情是t2类不是这样。它们是天壤之别。
While the t1 class was almost completely unsuited to a production environment, the same thing is not true of the t2 class. They are worlds apart.
如果您的代码紧凑且内存高效，并且您的工作量适合基于cpu信用的模型，那么我同意您的分析
If your code is tight and efficient with memory, and your workload is appropriate for the cpu credit-based model, then I concur with your analysis about the excellent value a t2.micro represents.
当然，这是一个巨大的如果。但是，我的网络中有一些系统非常适合此模型-它们的内存几乎完全在启动时分配，并且它们的负载相对较轻，但一天当中变化很大。只要您不会用尽您的信用余额，这种方法我就不会有错。
Of course, that's a huge "if." However, I have systems in my networks that fit this model perfectly -- their memory is allocated almost entirely at startup and their load is relatively light but significantly variable over the course of a day. As long as you don't approach exhaustion of your credit balances, there's nothing I see wrong with this approach.
这篇关于比单个t2.small或t2.medium好几个t2.micro的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！