The best setup depends on a lot of factors:
- Avg. source image size in bytes. (Increases network bandwidth requirements)
- Source image size in megapixels. (Increases RAM requirements).
- Result image size in bytes. (Increases disk space requirements)
- Source image count. (Increases blob storage requirements, network bandwidth requirements)
- Avg. output versions per source image. (Increases cache disk speed and size requirements)
- Active vs. archived image sets. What percentage of the image set gets 90% of the traffic? (Affects cache tuning and CDN usage)
- What kind of authorization rules need to be applied? DiskCache can do anything, but CDNs can only do expiring links.
- What format are the source files and output files in? PNG is 10x slower per megapixel than JPEG - by design. TIFFs can contain any type of compression algorithm - some are fast to decompress, some are algorithmically glacial.
It's not uncommon for network bandwidth to be the bottleneck, especially if you're using blob storage.
I generally recommend starting with 3.75-8GB RAM per instance, and as many web garden instances as available core, then benchmarking.
We do not currently publish benchmarks on virtual instances, as performance is very dependent on what other virtual instances on the same hardware are up to.
AFAIK, none of our users (even those with petabytes of images) have needed to scale out past 3 nodes for speed; usually even those are simply for availability.
The best thing to do is download the software and test it with your data. There are too many variables for a cookie-cutter benchmark to be useful to you, and the only significant cost would be several hours of your time. Installation is typically about 5 minutes, but provisioning VMs can take a while.