4 ms·
That's another way of saying your typical utilization ratio is 66%. Which is on the low side honestly. That said, it's a trade off between efficiency and load
by kccqzy 3y ago
That's another way of saying your typical utilization ratio is 66%. Which is on the low side honestly.
That said, it's a trade off between efficiency and load spike tolerance. I trust that the trade off is made with informed decision.
- rewmie 3y ago> That said, it's a trade off between efficiency and load spike tolerance. I trust that the trade off is made with informed decision. I don't think that relatively low utilization rates is the scenario that requires "informed decision". The only tradeoff in low utilization rate scenarios is cost, which might be outright cheaper and irrelevant once you do the math on the tradeoffs of using reserved instances vs the cost of scaling up with on-demand instances. You need to make a damn good case to chronically underprovision your system and expect it to autoscale your way into nickle-and-dime savings.
- ec109685 3y ago66% isn’t low utilization. You’re always going to have micro spikes, and you never want to clip, so keeping some headroom around feels smart. Unless you co-mingle online and offline (batch) traffic on same hosts, flat response times and high utilization aren’t compatible.
- sitkack 3y agoHigh utilization means high variability and low resiliency and the last k-percentage of utilization causes highly non-linear effects.
- ec109685 3y agoSmart budgeted retries can help smooth those peaks.
- kccqzy 3y agoWhile I agree there's always going to be micro spikes and keeping some headroom is smart, 33% may be too much of a headroom for all but the most latency sensitive RPC services. Personally I aim for only 20% headroom.