3 ms·
Take a peek at the "Real" versus "User" numbers in the linked post. We were expecting to see that Micros perform well for short but intensive bursts, but that w
by jashkenas 16y ago
Take a peek at the "Real" versus "User" numbers in the linked post. We were expecting to see that Micros perform well for short but intensive bursts, but that wasn't the case.
When the Micro went to OCR 51 pages of document text, it spent only 6 minutes of actual CPU time to do it. Unfortunately, those 6 minutes of CPU time were spread over a real wait of 52 minutes, due to either other users on the machine, or Amazon caps. That's not so great for an intensive burst.
Perhaps it would work if the CPU burst lasted for seconds instead of minutes, but I wouldn't bet on it. It would be a nice benchmark to try...
- babo 16y agoIn the AWS documentation an optimal burst is like in the 200ms range, not even seconds.
- jashkenas 16y agoThanks for looking that up. I wonder what sort of intermittent CPU-intensive tasks are a good fit for that size of a burst. Are you using the Micros in this fashion?
- babo 16y agoI haven't found an application which is following that pattern yet. Probably running a proxy in front of a bunch of micro instances is a good idea, that will distribute the load evenly why adding the required redundancy and speed improvement over small instances.
- saurik 16y agoA website with almost no users is going to need to execute every now and then for only 200ms at a time.