4 ms·
Just for a data point; We have been serving around 10 million web requests / day per t2.medium. Not lightweight static files or small json responses, actual dy
by eknkc 9y ago
Just for a data point;
We have been serving around 10 million web requests / day per t2.medium. Not lightweight static files or small json responses, actual dynamic pages with database load. Our servers mostly sit around 20% though.
Might not be that much compared to larger web services but we have a localised audience so nighttime cpu credits get collected and used during peak times. So it fits our workload. They are great value when the credit system work in your setting.
Have a grafana dashboard constantly monitoring credits and have alerts in place though. But haven’t had a sudden issue that we needed to manually remedy.
- Xorlev 9y ago> Have a grafana dashboard constantly monitoring credits and have alerts in place though. This, otherwise your infrastructure will come grinding to a halt at the worst time. It's a potential DoS vector in that way too, if you're relying on charging up credits overnight to handle traffic during the day.
- scoates 9y agoCan help avoid that with the even-newer t2.unlimited [1] instances, it seems. [1] https://aws.amazon.com/blogs/aws/new-t2-unlimited-going-beyond-the-burst-with-high-performance/ https://aws.amazon.com/blogs/aws/new-t2-unlimited-going-beyo...
- jlouis 9y agoCounter data point, my erlang nodes on t2 often reports lockups of more than 400ms. This is not acceptable when queries are handled in 10ms on a typical day. Erlang had built in monitoring when the underlying system scheduler makes a error