eCommerce in the Cloud: Best Practice 2 of 5

The second part of this five-part series on best practices for deploying eCommerce applications to the cloud will focus on site performance.  It has been shown that even a slight decrease in performance can have a large negative impact on revenue.  Without a doubt, this makes performance of prime importance when architecting and deploying for the cloud.

Best Practice #2: Performance Is a Business Requirement

I wrote a post to this blog that described the importance of site performance and how revenue might be affected by poor response time.  The highlights are:

  • If Google response time is slowed by only 0.4 of a second, there are 8 million fewer searches completed per day
  • There is a 25% abandonment rate when a web page takes more than 4 seconds to render
  • There is a 50% mobile abandonment rate for a ten second render time.

And here’s a striking extrapolation drawn from this data:  Amazon makes about $67 million in sales per day. It could potentially lose up to $1.6 billion per year because of a 1 second page delay.  My guess?  Mr. Bezos knows this and makes sure that $1.6 billion is not at risk.

Here are a few ways to improve site performance, especially during high volume periods:

Cache at different levels

  • Caching Pages: For high-volume static pages, consider a CDN such as Akamai, Amazon CloudFront and others.  For content that is dynamically but not for every request, consider things like Varnish to remove processing burden from the Application Server layer.
  • Caching Session Data: Maintaining session data and keeping it available for requests that might be handled by one of many web or application servers can be an arduous task.  Using technologies like memcached can ease the burden and provide scalable solutions for session management.
  • Caching database query results: On many eCommerce sites, search queries entered by one user may also be entered by other users, especially if you have a site that serves a niche market.  Consider caching result sets from popular queries so that response time is increased.  For example, if a user enters “Canon Lens” as a search on a photography eCommerce site, and you know from your analytics data that users search for that 1000 times per day, run the query the first time a user enters the search term and cache the result set.  The next user that enters that term will be treated to the same result set with a much faster response time.

Build representative test cases

If you know your target market well, and you’re paying attention to analytics (you are paying attention, right?) you will have enough information to build test cases that imitate shopping behavior on your eCommerce site.  Create test cases that measure for performance during high-volume periods, multiple search terms, and environmental changes such as scaling up and scaling back.  The cloud is a great way to ramp up environments that run such test cases against your site, gather great data, and ramp down when the testing is over.

Measure performance metrics

In addition to the due attention you give analytics data, also make sure performance metrics are carefully monitored.  Monitor percentage of processing power used, network bandwidth used, available disk space and similar metrics at each layer of your environment.  By monitoring performance metrics you can determine a suitable point for scaling a layer of the environment up or down.  This keeps response time quick for the consumer while keeping operating costs at an acceptable level.

Server AND Client performance

Don’t forget that some performance issues can occur on the user’s browser as well.  Poorly written JavaScript, or JavaScript files that can’t be downloaded quickly and cached, can create a perception that a site is slow.  Optimize all JavaScript and serve it from a CDN or similar environment to boost page load times.

In addition, consider moving some logic to browser when feasible.  For example, if a site is running a promotion that offers a percentage discount based on a certain number of specific items in the cart, that business logic could be coded in JavaScript instead of having to make a round-trip to the server to validate the discount.  Of course, there could be some security concerns so you should always validate the final calculation and cart contents just prior to checkout at the server.

To see the complete presentation, view the webinar here and tell me what you think in the comments below.

Add Comment