AWS Performance Tip 3: Use Amazon ElastiCache to improve application performance

Web Applications can be often made to perform better and run faster by caching critical pieces of data in memory.  Frequently accessed data, layers of HTML fragments, results of time-consuming/expensive database queries, search results, sessions, results of complex calculations and processes are usually very good candidates for cache storage.  In general application architectures that are read intensive will usually have better performance gains using cache tiers. In web scale applications, distributed caching has become a mandatory part of the architecture stack to improve performance.

AWS introduced ElastiCache for this purpose. ElastiCache is fully compliant with MemCached and applications already using MemCached can easily migrate their code to Amazon ElastiCache. ElastiCache serves data from RAM, and execute all the simple operations (such as SET and GET) with O(1) complexity. Amazon ElastiCache large node can do 40k+ RPS throughput easily, this approach is far more performing than relying on database for everything.Refer the following benchmark from garantiadata to understand how memcached/elasticache can add performance to your architecture. http://garantiadata.com/blog/its-true-even-modest-datasets-can-enjoy-the-speediest-performance. 

Using Amazon ElastiCache distributed caching tier in your architecture, you reduce the overall read load in your database and increase the overall performance of your application. Request/response latency can be reduced to few milliseconds using Amazon ElastiCache in your architecture.Since Amazon ElastiCache is a volatile in nature and the items have TTL's it is recommended to fall back to DB or source data stores in event of cache miss.

To know more about Amazon ElastiCache please deep dive into this article here : http://harish11g.blogspot.in/2013/01/amazon-elasticache-memcached-internals_8.html

 

AWS Performance Tip 2: Use Page Cache-Web Accelerators to reduce Latency

Tip : Deliver your content from the edge of your architecture stack.
Imagine you have online application with Multi-tiered architecture comprising of Security Tier, Load Balancing Tier, Web tier, Application tier and Caching tier etc. Information has to travel through all these tiers to hit the caching layer and deliver the response back many times. This might take couple of hundred's of milliseconds sometimes depending upon the processing needs and network latency in the AWS infra . This overall latency might not be acceptable for certain use cases which needs sub second content delivery to the end users. 
Instead of delivering your frequently accessed contents from the deep caching tier, You can re-architect your stack a little and try to deliver content from entry point itself. Solutions like Varnish, aiCache and NetScaler specialize in this caching and acceleration techniques and are widely used in AWS infra by architects. AMIs of these products are available on the AWS marketplace and many customers have already put them on production use. These products have the capability to cache/compress pages, objects, URL etc and by placing them at the entry of your architecture you will reduce the latency, save precious back end compute cycles and save costs by reducing the instance capacity needed at the backend.  In case you use NetScaler Amazon EC2 it comes with sophisticated Load balancing algorithms as well, this way you can cut an extra LB tier and merge both cache+LB together to achieve high performance at low latency. Since these products are at the entry and have heavy dependency on bandwidth and memory, it is recommended to use EC2 instances with High IO and Memory capacity for these products. 
This architecture implementation is a useful technique and can be widely adopted on segments like online newspapers/news, blogs ,content management systems, online classifieds use cases etc in AWS, which has lots of static content that does not change quite frequently and can be delivered again and again from the page cache-web accelerators tiers itself. 

Related Articles :

Cost of Latency and Route53 LBR
Varnish Deployment Architectures in AWS

AWS Performance Tip 1: Use Amazon CloudFront to reduce latency

Amazon CloudFront is a content delivery web service that helps you to distribute content to end users with low latency and high data transfer speeds. Amazon CloudFront has growing network of edge locations that cache copies of popular files(images, JS, CSS, videos etc) close to your viewers and makes sure that end-user requests are served by the closest AWS edge location.Since requests now travel shorter distances to request objects (lesser hops) + the additional optimizations done in Amazon CloudFront like TCP initial congestion window, reduces the overall latency and improves the performance to your users.
Imagine your user is accessing a content hosted in AWS Europe from Singapore, it takes ~120 milliseconds as latency for this delivery, whereas if the same content is delivered from AWS Singapore using Amazon CloudFront, the latency can be reduced to ~10 milliseconds. If your site is content heavy multiply the above with number of requests, hops etc and imagine the latency savings that Amazon CloudFront can provide. 

Internally Amazon CloudFront maintains persistent connections with the content origins so that changes/addition can be picked quickly. 

Following diagram illustrates current list of edge locations offered by Amazon Web Services. Keep watching  http://aws.amazon.com/cloudfront/#details for updates, more edge locations around the world are on your way.

5 Essentials every architect should know about SimpleDB

1:Shard the Data 

Spread the data among Multiple SimpleDB Domains for better throughput. Many benchmarks from Internet suggests a single SimpleDB domain can handle 70 puts/sec/domain. Every account by default can create 250 SimpleDB domains and more domains can be added by filling this form.

http://aws.amazon.com/contact-us/simpledb-limit-request/

Example Lets assume a Single SimpleDB domain offers 70 puts/sec/domain. Your application layers requires a conncurrency throughput of 7000 req/sec. In order to increase the overall write/read efficiency shard the data into 100 simpleDB domains.

2:Retries and Exponential Backoff

Amazon SimpleDB is a webservice call and you may encounter 500,503 errors sometimes. The usual technique for dealing with such error responses in AWS

is to implement retries in the application layer. The application implementing this technique can maintain excellent level of performance and availability because it can automatically handle the overload and server errors. This technique also increases the overall reliability of the applications consuming Amazon SimpleDB service.

In addition to simple retries, the best practice is using an exponential backoff algorithm for better flow control. The algorithm logic has to be built in your application layer code. The concept behind exponential backoff is to use progressively longer waits between retries for consecutive error responses: up to 500 milliseconds before the first retry, up to 1500 milliseconds before the second, up to 6000 milliseconds before third, and so on. The timings can vary depending upon your use case.

Refer this URL for more information : http://aws.amazon.com/articles/Amazon-SimpleDB/1394

3:Run from Amazon EC2
Amazon SimpleDB gives better performance in terms of latency if we execute the queries from Amazon EC2 . This is because network round trips are avoided  when the web service calls are made from Amazon EC2. By default SimpleDB domains are created in USA-EAST AWS region. Applications accessing SimpleDB from APAC, Brazil, Tokyo AWS regions etc should make sure they select Amazon SimpleDB and Amazon EC2 from same region to get better performance. Also the network bandwidth usage is free within Amazon Region between EC2 and SimpleDB.


4:Query optimization

• Use BatchPut API instead of PutAttributes for better write performance. BatchPut API takes 25 items (or 256 attributes or 1MB request size) on a single domain. It works like Batch commit in RDBMS , so in case of failure all items are reverted. We have observed write throughput of 20X using BatchPut compared to single Put API.
• Avoid Non Indexed Queries like "Select * from Domain..." in Amazon SimpleDB
• When storing dates, it is recommended that you store all dates in Joda time and use a single time zone
• Zero Padding for sorting ( based on  largest number in your Data set)
• Make sure you design Queries in Amazon SimpleDB domains that it will not run more than 5 seconds , beyond which Amazon SimpleDB will return error or clip them

5:Understand the SimpleDB limits

There are also certain limits that Amazon SimpleDB enforces which applies to the domain data size, domain names, query execution time, result set size, etc…please understand them before designing applications using SimpleDB

http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/SDBLimits.html?r=7516




Related Articles

http://aws.amazon.com/articles/Amazon-SimpleDB/1232

http://aws.amazon.com/articles/Amazon-SimpleDB/1394