Table of Contents
- High Performance Cloud Apps
- Test Setup
- Test Results
- Appendix: Recreating the Test
- About Microsoft
- About William McKnight
- About Jake Dolezal
Applications and their performance requirements have evolved dramatically in today’s landscape. The cloud enables enterprises to differentiate and innovate with APIs and microservices at a rapid pace. Cloud providers, like Azure, allow microservice endpoints to be cloned and scaled in a matter of minutes. The cloud offers elastic scalability compared to on-premises deployments, enabling faster server deployment and application development and less costly compute.
Likewise, databases play an important role in modern applications and microservices. Fully-managed database services in the cloud are being adopted by industries in all verticals. They offer many advantages over hosting on-premises, including the speed of development and deployment and relieving the administration and maintenance burden.
This report focuses on a web application deployed in Azure with a backend database under a heavy read/write load. Under such loads, the time it takes to access or write data may cause high application response latency and delay further transactions. Latency is specifically a problem with read and write-intensive applications that include high volumes of user or machine traffic.
Many organizations depend on their apps, APIs, and microservices for high performance and availability. For this paper, we define “high performance” as companies who experience workloads of more than 1,000 transactions per second (tps) and need sub-second latency across their landscape. For these organizations, performance is an essential requirement, equal to availability and security, because they rely on these transaction rates to keep up with their business speed. Thus, an application’s underlying database solution must not be a performance bottleneck.
Moreover, many of these companies are looking for a distributed solution to load balance across redundant applications and enable high transaction volumes. If a business experiences 1,000 transactions per second, this translates to 3 billion API calls in a month. Thus, performance can be a critical factor when architecting an application.
In this paper, we reveal the results of application performance testing we completed both with and without Azure Cache for Redis on top of Azure SQL Database and Azure Database for PostgreSQL.
For our test, API requests came back with the lowest latencies and highest throughput by far when Azure Cache for Redis was used. The additional cost of Azure Cache for Redis is negligible. We recommend that any Azure Database for PostgreSQL or Azure SQL DB application anticipating over 1,000 tps eliminate the latency concern by adding Azure Cache for Redis, which provides over 800% performance gain to the 8 DB vCores configuration in our test. Considering the negligible cost of Azure Cache for Redis, it might be possible to achieve significant performance while reducing costs with less expensive database instances. Also, even though 1,000 tps is a high-end transaction rate, Redis is applicable at transaction volumes of any size. You don’t need to max out your DB before you can benefit from a cache.
Testing hardware and software in the cloud is very challenging. Configurations may favor one system over another in feature availability, virtual machine processor generations, memory amounts, storage configurations for optimal input/output, network latencies, software and operating system versions, and the workload itself. Even more challenging is testing fully managed, as-a-service offerings where the underlying configurations (processing power, memory, networking, and the like) are unknown. Our testing demonstrates a narrow slice of potential configurations and workloads.
This is a sponsored report. Microsoft chose the backend database and Azure Cache for Redis configurations. GigaOm chose the test methodology, set up the infrastructure, and ran the testing workloads. Choosing testing configurations is subject to judgment. We have attempted to describe our decisions in this paper.
We leave the issue of fairness for the reader to determine. We strongly encourage you, as the reader, to look past marketing messages and discern for yourself what is of value. We hope this report is informative and helpful in uncovering some of the challenges and nuances of application data architecture selection.
We have provided enough information in the report for anyone to reproduce this test. You are encouraged to compile your own representative workloads and test compatible configurations applicable to your requirements.