We did compare load times later on to our 1.1.8 install, and 1.3 was a little faster, but not much. Of course, we would try to keep up to date with recent versions (bugs pending) anyway.

I might look into the elastic block store volumes. I have heard from a few other sources that EC2 IO is a little slow. Next thing to try is a few larger instances.

Ideally a product base of this size would be installed on a dedicated webserver machine (of load balanced servers) with dedicated database backend. Like I said in my post it was by no means a detailed or exhaustive test, but it did show some good gains with caching (and flat catalog cache) enabled.

Our 1.1.8 production server has a dedicated back end database server, so more improvements should be gained in upgrading 1.1.8 in that configuration.
The target of <2 seconds per page load is a good one.

We also have a load balancer setup now, so it is more or less easy to throw more server units from the EC2 service into the pool to boost performance. We may try that shortly.

Of note, we also experienced very slow product save times with a database of products that size. It didn’t seem to matter whether products were shared amongst website and stores or not. As we removed products from the database, the product save time (updating a price for example) decreased proportionately.

Having everything on one machine makes it impossible to determine what might cause the pages to return more slowly. clearly your sytem bottlenecks, but at which stage is confused. I have found that amazon IO speed to be a bottleneck. running the app from an elastic block store volume can make a big difference. The size of processor will cause processor bottelnecks durring processing.

Have you considered performance testing a your current 1.1.8 system against the same system using 1.3 to see if it is worth upgrading. Or using the amazon system to build large more scalable systems to determine the real world resources you need to achieve acceptable speed (<2 seconds per page)

Cheers,
Richard