Cloud Performance – Why Long Distance Relationships Don’t Work
As companies turn to SaaSas a low cost, highly scalable, and agile way to host new applications, a number of cloud performance management and monitoring solutions are appearing. Salesforce led the CRMs in moving off of dedicated hardware, and other types of applications like email, project planning, and even EHR have followed suit. Moving away from installed software side-steps a lot of common problems like server crashes or hardware failures, but it also introduces new issues. To cope with this, there are applications popping up to perform load testing against your cloud infrastructure, some of which are even developed and hosted by the providers themselves, likeGrinder in the Cloud andPylot, as well as a number of commercial services. While these tools are needed and can be quite valuable, they all miss one of the most critical aspects of performance monitoring: the physical distance between your users and the cloud infrastructure.
Why Location Matters: TCP
The majority of SaaS applications are standard web applications running on top of TCP. Because TCP is location dependent, the physical distance between your users and the datacenter has a dramatic impact on the maximum achievable performance you will see from the cloud. As this example details, the latency on a network connection can be the biggest factor in the end-to-end performance. A 1Gbps WAN connection from New York to Chicago with latency of 30ms has a maximum achievable throughput of 17.4 Mbps. That distance between New York and Chicago just cost you 98% of the capacity you are paying for. Take that RTT up to 80ms, which is your RTT round trip from one coast to the other in North America, and your 1Gbps link has only 6.4Mbps achievable. Finding out where the application datacenters are should be one of the critical questions to be answered before signing on with any cloud provider.
3’s a Crowd: Plugins
Many SaaS applications only provide multiple locations for redundancy. Some, like Salesforce, let you choose between a handful of locations to minimize the RTT. Even if you can solve issues with Salesforce itself, the plug-ins to the Salesforce platform can have as big an impact to your performance as the core application. When choosing between plug-in vendors, make sure you test their user experience as well, and ask if they have multiple, geographically distributed data centers to choose from.
You also want to consider the degree to which a SaaS application is exposed to performance degradation based on location. When you go to a new page in Salesforce, there are 80 or 90 objects being transferred back and forth, and each one of those objects has a TCP handshake to get started. You may think it’s just 200 milliseconds for your office in Tokyo to connect to your Salesforce instance, but it’s actually 200 milliseconds plus 5 seconds of handshake for each of the 80-90 objects. It can take you 8 seconds just to make the initial connection and then you still have the transfer times.
The size of page files is also going to impact the upload time. Consumer-centric sites tend to aggressively shrink page sizes, but many SaaS apps focus on functionality over speed. This can mean page sizes of multiple megabytes per screen: up to 5MB in Salesforce, for example. For users who are on Salesforce for hours, those extra seconds per page really add up when over 100s of pages, making the experience extremely frustrating.
The low cost and high performance of the Cloud is changing the way IT is delivered. How will you manage the end user experience of your applications?