5 ms·

This would be excellent if you could accrue more than the 72 minutes worth' of CPU credits. At least my use case is 'low traffic, with the occasional link from

This would be excellent if you could accrue more than the 72 minutes worth' of CPU credits. At least my use case is 'low traffic, with the occasional link from a high-traffic site'. These happen every few months, not every three days. But they also last 36 hours or so, not 72 minutes. Total CPU usage is similar, but it's distributed differently.

cperciva 11y ago
There's a trade-off between how much they allow you to spike and how long they allow you to spike for. They could have 20 t2.nano instances packed onto one CPU; the longer you can spike for, the more likely it is that another instance is going to end up spiking at the same time as you. I'm sure Amazon has looked at the CPU-usage behaviour of millions of EC2 instances -- quite likely across hundreds of billions of data points -- and picked this as a reasonable tradeoff. For your use case, I think autoscaling is probably the answer. Keep one t2.nano running continuously but tell EC2 to spin up a new t2.large if you get a burst of traffic.
- matt4077 11y ago
  Yeah, they obviously put more thought into this than I ever will. Although they offer instances with 40 (v)CPUs so I'd assume they could technically run 800 nanos on one of those and efficiently deal with such spikes? Either way, I suspect their reasoning is more economical than technical, in that they know full well that I can afford more than 5$/mo. (which I'm taking to linode for now, but oy vey, AWS, we'll always have Paris)
  - cperciva 11y ago
    Right, these are presumably running on boxes with many CPUs each. Whether instances migrate, I don't know; due to NUMA concerns they might be pinning instances to cores. The other issue to consider is correlated spikes: When you aggregate 800 instances, you're probably going to see a pretty clear diurnal cycle. (And quite possibly middle-of-the-night spikes as synchronized cron jobs all kick off, too.)
  - copperx 11y ago
    > more than 5$/mo. > (which I'm taking to linode for now, Just curious, what does $5/mo buy you on Linode?
    - matt4077 11y ago
      Check it out yourself: https://www.linode.com/pricing https://www.linode.com/pricing. As I said, "more than 5$", in this case meaning 10$, which gets me a CPU core and 24GB of ssd storage. It replaced a dedicated server that was 50€/mo. That server had probably 8 to 10 times the power but the vpn solution can scale within two minutes if needed. I was also having suspected hardware trouble with the dedicated server that the provider couldn't diagnose / wouldn't replace. It's an incredibly boring setup that serves about 200 visitors on a normal day, 2000 during a handful of spikes /year. I know I could probably run it from a Casio watch but it generates six-figures of revenue / year so a bit of overkill is justified.
      - copperx 11y ago
        Could you explain, if possible, how do you get six figures revenue from 200 visitors?
lotyrin 11y ago
It still is excellent, because it reduces both the granularity and baseline cost of an autoscaling setup which is probably what you want for your use case.
jdub 11y ago
That's what CloudFront[1] is for. :-) [1] ... and an async web server without hitting a dynamic backend on every page load...

cperciva 11y ago

There's a trade-off between how much they allow you to spike and how long they allow you to spike for. They could have 20 t2.nano instances packed onto one CPU; the longer you can spike for, the more likely it is that another instance is going to end up spiking at the same time as you. I'm sure Amazon has looked at the CPU-usage behaviour of millions of EC2 instances -- quite likely across hundreds of billions of data points -- and picked this as a reasonable tradeoff. For your use case, I think autoscaling is probably the answer. Keep one t2.nano running continuously but tell EC2 to spin up a new t2.large if you get a burst of traffic.

matt4077 11y ago
Yeah, they obviously put more thought into this than I ever will. Although they offer instances with 40 (v)CPUs so I'd assume they could technically run 800 nanos on one of those and efficiently deal with such spikes? Either way, I suspect their reasoning is more economical than technical, in that they know full well that I can afford more than 5$/mo. (which I'm taking to linode for now, but oy vey, AWS, we'll always have Paris)
- cperciva 11y ago
  Right, these are presumably running on boxes with many CPUs each. Whether instances migrate, I don't know; due to NUMA concerns they might be pinning instances to cores. The other issue to consider is correlated spikes: When you aggregate 800 instances, you're probably going to see a pretty clear diurnal cycle. (And quite possibly middle-of-the-night spikes as synchronized cron jobs all kick off, too.)
- copperx 11y ago
  > more than 5$/mo. > (which I'm taking to linode for now, Just curious, what does $5/mo buy you on Linode?
  - matt4077 11y ago
    Check it out yourself: https://www.linode.com/pricing https://www.linode.com/pricing. As I said, "more than 5$", in this case meaning 10$, which gets me a CPU core and 24GB of ssd storage. It replaced a dedicated server that was 50€/mo. That server had probably 8 to 10 times the power but the vpn solution can scale within two minutes if needed. I was also having suspected hardware trouble with the dedicated server that the provider couldn't diagnose / wouldn't replace. It's an incredibly boring setup that serves about 200 visitors on a normal day, 2000 during a handful of spikes /year. I know I could probably run it from a Casio watch but it generates six-figures of revenue / year so a bit of overkill is justified.
    - copperx 11y ago
      Could you explain, if possible, how do you get six figures revenue from 200 visitors?

lotyrin 11y ago

It still is excellent, because it reduces both the granularity and baseline cost of an autoscaling setup which is probably what you want for your use case.

jdub 11y ago

That's what CloudFront[1] is for. :-) [1] ... and an async web server without hitting a dynamic backend on every page load...