6 ms·

As I myself learned the hard way, T2 are awful for production websites with sustained high traffic. The author points out the biggest issue: “About 40 minutes

As I myself learned the hard way, T2 are awful for production websites with sustained high traffic. The author points out the biggest issue: “About 40 minutes into Hour 6 your instance no longer has any credits remaining. At this point, you’re now limited to the baseline performance of the instance, in this case, 10% of the vCPU. At this point your application grinds to a halt.” Agreed. As terrible as that is, it’s actually worse than that in my experience, bc even while you have positive CPU credits, you can’t spend them down smoothly to achieve high sustained CPU - the scheduler gives you something more like a sine wave of performance. Which is mystifying to say the least and leads me to my final point about why T2 is so awful: it violates the principle of least astonishment. Why would anyone expect that a CPU is limited to a small fraction of its output? T2 should not be categorized in the “general computing” aws instance family. It should be in a family all its own called “burstable” that explains the major difference between it and the general computing family.

rtisdale 8y ago
Howdy, I'm the author :) I definitely agree, for high traffic applications a compute or memory optimized instance are more optimal choices due to the consistent performance, especially when price isn't as much of a concern. In situations where cost is more of a concern and the application has "bursty" requirements for performance, I still believe the T2 instance has it's place. The guys over at Cloudonaut have an excellent article on the importance of T2 burst credits to maintain application performance. https://cloudonaut.io/burst-credits-of-t2-ec2-instances-need-monitoring/ https://cloudonaut.io/burst-credits-of-t2-ec2-instances-need... EDIT: The new T2 Unlimited option mentioned at the above article is also worth considering.
sudosteph 8y ago
Back when I worked at AWS and t1s were still the big thing, we had a policy of telling customers to never run a production site on a t1.micro . I would say the same about t2s for the most part. AWS needs to do a better job of putting big red warnings all over the docs or console or something. Even though the details really are all there in the docs, it's very easy for people to get lulled into a sense of false security if they're following along with a blog post or just not going over the docs in depth. But really, reading the service docs in depth, does pay off. Totally agree that it should not be "general computing" categorized though. That category in general is too vague to be useful really. They should clearly demarcate between production service hosts and development-oriented instance types.
- jedberg 8y ago
  > we had a policy of telling customers to never run a production site on a t1.micro It's perfectly safe to run a production site on a t1.micro, as long as you follow good principles regarding monitoring and autoscaling. You'd be a fool to run a production website on any instance type without those failsafes, but with them in place, a t1/t2.micro is no worse than any other. And in fact, since they boot so quickly, they are really nice with auto-scaling.
  - sudosteph 8y ago
    I should clarify, "single t1.micro". Some customers just really refused to do any autoscaling config at all, so best we could do is show them how to backup and restore. But it's true that t1s really were very inconsistent in performance compared to the other families. T2s may be better, but I don't have insight on that.
_pmf_ 8y ago
What would be the purpose (for the layman)? Handling spikey event ingress?
- Fomite 8y ago
  I have a very simple web app that is, when being used (rarely) is fairly computationally demanding (in a relative sense). That kind of load suits the T2 instance really well in my experience.
- sudosteph 8y ago
  They're still good for: - non production dev servers - executing recurring scheduled events with known estimate for cpu usage (cron jobs) - potentially for non-overly busy build servers I wouldn't use them for anything that needs production reliability though.
not_kurt_godel 8y ago
> T2 are awful for production websites with sustained high traffic I mean, their entire purpose and value proposition is explicitly based on not needing to support sustained high traffic. This is not something that needs to be learned the hard way. You don't even need to RTFM, you just need to read the first sentence of the first Google result snippet: > T2 instances are low-cost, General Purpose instance type that provide a baseline level of CPU performance with the ability to burst above the baseline. In fact, they are even explicitly labeled as "burstable performance instances" as you suggest in the first five words of the first paragraph of the first Google result for "aws t2": https://aws.amazon.com/ec2/instance-types/#burst https://aws.amazon.com/ec2/instance-types/#burst

rtisdale 8y ago

Howdy, I'm the author :) I definitely agree, for high traffic applications a compute or memory optimized instance are more optimal choices due to the consistent performance, especially when price isn't as much of a concern. In situations where cost is more of a concern and the application has "bursty" requirements for performance, I still believe the T2 instance has it's place. The guys over at Cloudonaut have an excellent article on the importance of T2 burst credits to maintain application performance. https://cloudonaut.io/burst-credits-of-t2-ec2-instances-need-monitoring/ https://cloudonaut.io/burst-credits-of-t2-ec2-instances-need... EDIT: The new T2 Unlimited option mentioned at the above article is also worth considering.

sudosteph 8y ago

Back when I worked at AWS and t1s were still the big thing, we had a policy of telling customers to never run a production site on a t1.micro . I would say the same about t2s for the most part. AWS needs to do a better job of putting big red warnings all over the docs or console or something. Even though the details really are all there in the docs, it's very easy for people to get lulled into a sense of false security if they're following along with a blog post or just not going over the docs in depth. But really, reading the service docs in depth, does pay off. Totally agree that it should not be "general computing" categorized though. That category in general is too vague to be useful really. They should clearly demarcate between production service hosts and development-oriented instance types.

jedberg 8y ago
> we had a policy of telling customers to never run a production site on a t1.micro It's perfectly safe to run a production site on a t1.micro, as long as you follow good principles regarding monitoring and autoscaling. You'd be a fool to run a production website on any instance type without those failsafes, but with them in place, a t1/t2.micro is no worse than any other. And in fact, since they boot so quickly, they are really nice with auto-scaling.
- sudosteph 8y ago
  I should clarify, "single t1.micro". Some customers just really refused to do any autoscaling config at all, so best we could do is show them how to backup and restore. But it's true that t1s really were very inconsistent in performance compared to the other families. T2s may be better, but I don't have insight on that.

_pmf_ 8y ago

What would be the purpose (for the layman)? Handling spikey event ingress?

Fomite 8y ago
I have a very simple web app that is, when being used (rarely) is fairly computationally demanding (in a relative sense). That kind of load suits the T2 instance really well in my experience.
sudosteph 8y ago
They're still good for: - non production dev servers - executing recurring scheduled events with known estimate for cpu usage (cron jobs) - potentially for non-overly busy build servers I wouldn't use them for anything that needs production reliability though.

not_kurt_godel 8y ago

> T2 are awful for production websites with sustained high traffic I mean, their entire purpose and value proposition is explicitly based on not needing to support sustained high traffic. This is not something that needs to be learned the hard way. You don't even need to RTFM, you just need to read the first sentence of the first Google result snippet: > T2 instances are low-cost, General Purpose instance type that provide a baseline level of CPU performance with the ability to burst above the baseline. In fact, they are even explicitly labeled as "burstable performance instances" as you suggest in the first five words of the first paragraph of the first Google result for "aws t2": https://aws.amazon.com/ec2/instance-types/#burst https://aws.amazon.com/ec2/instance-types/#burst