As we have been using AWS for nearly 2 years to run JewelsBoutique.com, I’ve summarized a general process to optimize Magento under AWS (or other cloud-based LAMP stack) as below:

1. Capacity planning, be clear about how many items will be loaded into the system as well as the expected traffic volume (rough) in a certain period, this can help you choose the proper hardware resource (EC instance for AWS) at the beginning.

2. Apply commonly used ways to each separate component/sub-system of your system, e.g:

> Apache/Web Server: compile/configure the right mode & module, set proper parameters such as MaxClients, process threads, enable compressing module and set a never-expire header for static files if possible

> MySQL: set proper cache size, buffer and FS mode; apply the high-performance patch provided by Percona

> PHP: compile all needed extensions to be static, use at least one OP cache extension (eAccelerator/APC/xCache/ZO) and set the right parameters (caching mode, compressing level, etc.), set proper memory limitation

> OS: tune the FS/network related parameters, shutdown all unnecessary backend services (e.g. cups, portmap, etc.)

3. Once all of these are in place, let’s dig something more with Magento’s native support:

> Enable cache for all

> Configure backend cache type to be memory based (either shm FS or OP cache’s shm function)

> Use memory FS or database to save sessions

> Enable flat category/catalog, use Magento compiler if possible

> Use separate host (even a lighter web server on same server, but different port) to serve static files (/media/*, /skin/*)

4. Now, the system should be performing reasonably well, I believe the site should be OK to launch! Actually, my post was written at that point after we finished all items listed above – step by step – we experimented using different approaches to bring better browsing experience to those who shop for diamonds and engagement ring mountings on Jewelsboutique.com.

The next step will be much more interesting… also more challenging: monitor and detect the ‘performance optimizable area’ proactively, that could be either the slowest area of the system, or the place frequently called which could be bottleneck as traffic grows, here is a list that we have done/are doing based on our experience:

- Use separate server for database, web app and static files if needed

- Optimize Magento indexing strategy (we cannot easily upgrade to Magento 1.4, so need do something by ourselves with 1.3…)

- Build our own ’summary table’ for diamond search. As we have ~40,000 items, I can not imagine how slow Magento would be if using its own schema (even using flat-catalog)

There might be more specific cases when we were building JB, but that’s all what I remember and summarize at this point, I think we can go deeper for some specific problem if you guys have specifics you can share.

At last, I can share you the main stages that we have experienced since we started to run JB on AWS:

- Starting point – EC2 + S3: one small instance to host everything, write a script to backup data from EC2 to S3 everyday

- Soon after AWS brought out EBS, we moved to use EBS, all our ‘variable data’ (htdocs/database/logs) were stored on EBS, and we started to scale out — allocated more instances to run database and web server separately

- As backend/infrastructure-level performance are not big concern to us, we started to focus more on front-end/UX area, that what we are doing now — to improve our page look and feel, optimize the page structure to bring the web user convenient and useful information when shopping for diamonds and jewelry.

Angus