Hosting Magento Enterprise on AWS

Contributed by Vinci Rufus on 24 Nov 2012

• 
• Tweet
• Get in Touch

Amazon Web Services (AWS) is the most popular and robust Cloud Hosting Infrastructure. Millions of sites and some of Internet’s most popular sites, portals and eCommerce Sites run on Amazon.

Deploying Magento Enterprise on AWS for serving millions of users and a large catalog size would require a deeper understanding of Magento and AWS.

This blog talks about the architecture and points to consider while deploying Magento Enterprise on AWS.

The diagram below shows a recommended minimum architecture to deploy Magento for High Concurrent Traffic.

Given the architecture above, the following points / settings  need to be considered while setting up the servers

1. Make your App Servers Stateless:
   What this essentially means is to ensure that none of the user specific information like sessions, shopping bag contents etc are stored on the server. The sessions storage must be moved to the DB or Memcache. This will allow us to easily add or remove an app server, without the online users getting logged out or losing their shopping basket contents.
2. Do not enable sticky sessions on the Load Balancer:
   A load balancer is usually programmed to re-direct users to the app servers using a round robin method. However, if sticky sessions are enabled, then the load balancer will direct all traffic from a user to that one single server where the user’s session is created. While this works fine in most cases, there could be scenarios where the users connected to one server would be more active than the ones on the other. This would lead to an overload of one server while the other is relatively low on load. This would obviously affect the response times for users connected on the loaded server.
3. Ensure that the Media Folder is stored in an S3 bucket and is served via CloudFront:
   I’ve seen many deployments where the media folder, which contains all the product images and other static content is being duplicated across multiple app servers and is being rsynced each time a change happens. This is not ideal as the replication take time. While some users would be able to see the images, the other would not be able to. The ideal way is to have the media folder on a S3 bucket and have it served via Cloud Front (CDN) so that the images are served from the nearest node.
4. Put your CSS and JS also on CloudFront:
   Well that’s a no brainer! All static content should be served out of CloudFront. Don’t forget to concatenate, merge and minify the JS and CSS files. Magento is notorious in having 12-16 different JS files in their default and Enterprise themes.
5. Enable IOPS for your RDS Database:
   Relational Database Service (RDS) is usually the most preferred way to get your MySQL on AWS. RDS will make it really easy for you to get your database in Master Slave mode, and schedule automated data backups. However, RDS can turn out to be a bottle neck when it comes to high read-write cycles to the DB which Magento does a lot. This is because the RDS is essentially stored on a SAN which comes with its own latency problems. One way to overcome that is to enable IOPS for RDS to make sure the app servers can read and write data to the RDS database sufficiently fast.
6. CPU over RAM:
   Magento uses a lot more CPU than it uses RAM. So, while choosing an Instance, try and go for one that gives you more CPU power than RAM.
7. Use Memcache:
   Using a Memcache server will significantly improve the site’s performance. Also, it is important to ensure you have a bank of memcache servers running and have it properly configured in Magento, else your memcache server can become a single point of failure.
8. Use Nginx instead of Apache:
   During most of our load tests, we notice web servers being overworked most of the time and using most of the CPU power. Nginx has a much smaller foot print as opposed to Apache and can serve a significantly higher number of concurrent users than Apache.
9. Varnish can be a Double-Edged Sword:
   Many architects think that simply throwing in a reverse proxy like varnish before the app servers will help boost performance. But, that’s quite wrong. Putting Varnish in front of Magento Enterprise with ‘full page caches on’ can actually be counter productive especially if Varnish is configured to serve only images and static content. In many scenarios, it’s actually good to use APC instead of Varnish to improve speeds.

1. Disable xDebug:
   xDebug comes default within the Magento Installation and is quite useful for debugging the application during development. However, it will slow down the site while running in production mode.  Significant performance benefits can be achieved by disabling xDebug in Magento.

With the above configurations, we’ve been able to have our Magento Enterprise Portals serve 50+Million visitors with under 5 seconds of page load times during peak loads.

To know more about deploying your eCommerce applications on the Cloud, visit us here.

Visit us at Neevtech.com to know more about our offerings.

Tags: amazon, Amazon Web Services, CDN, CloudFront, low page load time, magento, magento aws, nginx, rds, varnish, xdebug