Elastic Applications That Scream: Optimizing Performance in AWS, Force.com, and Azure

If you are building an application in the cloud, on top of a modern elastic architecture, there is a good chance that you are looking to infuse your application with all the scalability, extensibility, and accessibility we have come to expect from the cloud. But this doesn’t just happen. You need to design attributes like this into your application from the start.

Optimizing application performance requires planning throughout development. Particular attention must be paid to performance:

  1. During the design process, when you are making fundamental architectural decisions, and
  2. At run-time, where you identify bottlenecks, carry out monitoring and measurement, and make improvements based on the flow of real users and real data through the system.

In this article, we will outline some of tips and best practices for optimizing application performance as suggested by three major elastic architecture services: Amazon Web Services, Salesforce’s Force.com Cloud, and Microsoft Azure.

1. Amazon Web Services

Amazon Web Services is one of the most comprehensive and flexible elastic computing architectures on the market. To build a scalable application it helps to know your way around its various components and services. Here are some things you can do to tune your S3 object store and your distributed EC2 environment.

Use an Appropriate Key Naming Strategy for S3 Objects
From Request Rate and Performance Considerations

If your requests are typically a mix of GET, PUT, DELETE, or GET Bucket (list objects), choosing appropriate key names for your objects will ensure better performance by providing low-latency access to the Amazon S3 index (discussed in the following section). It will also ensure scalability regardless of the number of requests you send per second.

When uploading a large number of objects, customers sometimes use sequential numbers or date and time values as part of their key names. But sequence patterns in key names can introduce a performance problem. Because of the way S3 stores key names, using a sequential prefix, such as timestamp or an alphabetical sequence, can result in concentrated activity on one single S3 partition.

If you anticipate that your workload will consistently exceed 100 requests per second, you should avoid sequential key names. One way to introduce randomness to key names is to add a hash string as prefix to the key name. Another is to reverse the order of the key so the initial characters are not all identical.

Put EC2 Instances behind an Amazon Elastic Load Balancer
From Best Practices in Evaluating Elastic Load Balancing

Elastic Load Balancing automatically distributes incoming application traffic across multiple Amazon Elastic Compute Cloud (Amazon EC2) instances. You can set up an elastic load balancer to load balance incoming application traffic across Amazon EC2 instances in a single Availability Zone or multiple Availability Zones. Elastic Load Balancing enables you to achieve even greater fault tolerance in your applications, plus it seamlessly provides the amount of load balancing capacity that is needed in response to incoming application traffic.

You can build fault tolerant applications by placing your Amazon EC2 instances in multiple Availability Zones. To achieve even more fault tolerance with less manual intervention, you can use Elastic Load Balancing. When you place your compute instances behind an elastic load balancer, you improve fault tolerance because the load balancer can automatically balance traffic across multiple instances and multiple Availability Zones. This ensures that only healthy EC2 instances receive traffic.

2. Salesforce’s Force.com Cloud

Force.com boasts over 4 million apps built on its platform designed for sales, service, and marketing applications, including a rich and active library of mobile apps. Giving your users a great experience requires some intimate knowledge about what’s under Force.com’s hood. Here are some suggestions from Best Practices for Deployments with Large Data Volumes.

Defer Sharing Calculation

If you work with large data volumes defer sharing calculation might be a great way to allow users to defer the processing of sharing rules until after new users, rules, and other content have been loaded. An organization’s administrator can use a defer sharing calculation permission to suspend and resume sharing calculations, and to manage two processes: group membership calculation and sharing rule calculation. The administrator can suspend these calculations when performing a large number of configuration changes, which might lead to very long sharing rule evaluations or timeouts, and resume calculations during an organization’s maintenance period. This deferral can help users process a large number of sharing-related configuration changes quickly during working hours, and then let the recalculation process run overnight between business days or over a weekend.

Reduce the number of records

The main approaches to performance tuning in large Salesforce deployments rely on reducing the number of records that the system must process. If the number of retrieved records is sufficiently small, the platform might use standard database constructs like indexes or de-normalization to speed up the retrieval of data.

Approaches for reducing the number of records include:

  • Reducing scope by writing queries that are narrow or selective
    For example, if the Account object contains accounts distributed evenly across all states, then a report that summarizes accounts by cities in a single state is much broader—and takes longer to execute—than a report that summarizes accounts by a single city in a single state.
  • Reducing the amount of data kept active
    For example, if your volume of data is increasing, performance can degrade as time goes by. A policy of archiving or discarding data at the same rate at which it comes into the system can prevent this effect.

3. Microsoft Azure

Ever since it was introduced in 2008, Microsoft has been steadily adding new capabilities to its Cloud Computing platform known as Microsoft Azure (formerly Windows Azure). Azure claims an advanced partitioning strategy that gives it a unique ability to parallelize tasks and achieve high performance. Here is some advice to help you make the most of that from Best Practices for Performance in Azure Applications:

Application Modeling

It is important to build a model of your application’s most important customer scenarios. Here, “important” means having the largest impact on performance. Identifying these scenarios, and the required application activities, will enable you to carry out proof of concept testing.

Proof of Concept Performance Testing

Full end-to-end performance testing is a critical step during application design and deployment. Based on the application model you built, next you should carry out proof of concept testing of your application as soon as possible, and load test it to validate the application architecture, to make sure that your application meets performance requirements in terms of scalability and latency. It is extremely important to validate your initial architecture and assumptions. You don’t want to find out that your application is unable to sustain the expected load when it goes live!

Physical location of services

If possible, co-locate different nodes or application layers within the same data center. Otherwise network latency and cost will be greater. For example, locate the web application in the same data center as the SQL Database instance that it accesses, rather than in a different data center, or on-premises.

Design, Test, and Monitor Performance to Scale Intelligently

There are lots of ways squeeze the last drop of performance out of your elastic architecture platforms, so hopefully these tips help. Just remember, though – just because your application is running on a system that enables it to scale out quickly and on-demand, doesn’t mean that performance problems are a thing of the past.

Our best advice is to design applications for scale and be conscious of their performance levels through testing and monitoring. Elastic architecture services don’t know the difference between an application with unoptimized performance and one under heavy load. Either way, they deal with maxed out performance the same way: by adding more servers. For a poorly designed application, this is only a temporary fix. Closely monitor your application’s performance, build thorough performance testing scenarios, conduct realistic load testing, and act accordingly.

One Response
  1. March 21, 2015

Leave a Reply

Your email address will not be published. Required fields are marked *