I recently got it into my head to migrate to AWS and Gallery3. As part of the migration to Gallery3 I stupidly converted all of my image resize versions to 640×480. This is pathetically small but only took overnight on the web server under my desk.
With everything now on the AWS server I thought it would just be a snap to crank them all back to the 800×800 resize versions. Boy was I wrong! Using a T1 Micro image gave me GREAT performance for the first 10 seconds, then I was throttled back on performance so that it would take DAYS to convert these 8000 image resize versions.
My top output showed 98%st, or 98% hypervisor stolen time from my virtual machine. No CPU for you!
I watched my steal time go through the roof after just a few images were processed!
Never fear though – this is a problem that can be solved with MONEY and time. I had a bit of both this Saturday morning (and some coffee!).
I took an AMI snapshot of my web server, created a new instance based on the LARGE template (7.5GB of RAM and 4CPUs!!!!) and said.. “Hey run my disk image on this large platform”. Now I can convert images to my heart’s content. However, this costs me about 34 cents an hour.. so once I’m done I’ll take another snapshot and say “OK, run these disks on the micro instance again. I’m done with all that extra horsepower.”
4 cores is WAY more CPU than I need… but I only get charged while I’m using it, and maybe it will speed things up. It’s easy to switch back and forth too!
With Elastic IPs I don’t even have to muck with DNS.
I just say “Hey Amazon, make my public IP point to the large instance, or small instance.” Then it’s updated on the fly. Very cool stuff!
Comments
One response to “Amazon AWS – LARGE Instance”
All that image processing took 5 hours. I think the charge was $1.70. It was WAY too much processing power for what I needed.