Ampere^® Altra^® processors are designed from the ground up to deliver exceptional performance for Cloud Native applications such as Elasticsearch. With an innovative architecture that delivers high performance, linear scalability, and amazing energy efficiency, Ampere Altra allows workloads to run in a predictable manner with minimal variance under increasing loads. This enables industry leading performance/watt and a smaller carbon footprint for real-world workloads such as Elasticsearch.

Microsoft offers a comprehensive line of Azure Virtual Machines featuring the Ampere Altra Cloud Native processor that can run a diverse and broad set of scale-out workloads such as web servers, open-source databases, in-memory applications, big data analytics, gaming, media, and more. The Dpsv5 VMs powered by Ampere Altra processors are general-purpose VMs that provide 2 GB of memory per vCPU and a combination of vCPUs, memory, and local storage to cost-effectively run workloads that do not require larger amounts of RAM per vCPU. The Epsv5 VMs are memory-optimized VMs that provide 4 GB of memory per vCPU, which can benefit memory-intensive workloads, including open-source databases, in-memory caching applications, gaming, and data analytics engines.

Elasticsearch, developed by Elastic, is a distributed, free, open-source search, and analytics engine for all types of data, including textual, numerical, geospatial, structured, and unstructured. Elasticsearch is built on Apache Lucene. Elasticsearch is known for its simple REST APIs, distributed nature, speed, and scalability.

In this workload brief, we compare the Ampere Altra-based Microsoft Azure Dpsv5 instances to the Intel^® Xeon^® Ice Lake-based Dsv5 and AMD EPYC™ Milan-based Dav5 instances in Azure running Elasticsearch while studying the throughput and latencies on each of these processors.

As seen in Figure 1, we measured up to a 3% performance advantage for the Dpsv5 VMs compared to the Dsv5 and 7% better than the Dasv5 VMs, all at a p.99 SLA of 100 ms.

On price-performance, the Dpsv5 VMs demonstrated compelling value – 28% better than the Dsv5 VMs and 26% compared to Dasv5.

Our tests were performed using the esrally as a load generator for Elasticsearch. Each test was configured to run with multiple clients. We used the http_logs dataset within esrally to benchmark Elasticsearch. This track is based on web server logs from the 1998 Football world cup.

It is recommended to use Elasticsearch with JDK-17 (compiled with GCC 10.2 with the architecture-appropriate flags) or newer, as recent JDKs have made significant progress towards generating optimized code for AArch64 applications. 

The Parallel GC garbage collector was used with appropriate memory and the number of threads. Elasticsearch data and logs were stored on Azure Premium SSDs. 

Ubuntu 20.04 was used with Elasticsearch 8.4.0. Elasticsearch provides the AArch64 package, which can be downloaded here (select Linux AArch64 in the platform option). For each of the tests, a similar number of esrally clients were used to generate requests. We used a bulk size of 1000.

Since it is customary to measure throughput under a specified Service Level Agreement (SLA), a 99th percentile latency (p.99) of 100 ms was used. This ensured that 99% of the requests had a worst-case response time of 100 ms. 

The test was run with warmup with the challenge append-no-conflicts-index-only, which is the common usage for Elasticsearch. This challenge indexes the whole document corpus using Elasticsearch default settings, since document ids are unique, hence all index operations are appended only. An appropriate number of clients to load one instance of Elasticsearch was initially used while ensuring p.99 latency was 100 ms.  At that point, throughput was used as the primary performance metric. The test was run three times and minimal run-to-run variation was observed. 

Elasticsearch is widely deployed in the cloud due to its scalability, ease of use, and extensibility. It is a popular choice for microservice-based applications, and it can be deployed on hundreds of nodes seamlessly making it a true Cloud Native workload, something the Ampere Altra processors were designed for. For cloud application developers, choosing Ampere Altra-based VMs on Azure means better performance and price-performance while reducing your carbon footprint.

For more information about Azure Virtual Machines with Ampere Altra Arm-based processors, visit the Azure blog.

All data and information contained herein is for informational purposes only and Ampere reserves the right to change it without notice. This document may contain technical inaccuracies, omissions and typographical errors, and Ampere is under no obligation to update or correct this information. Ampere makes no representations or warranties of any kind, including but not limited to express or implied guarantees of noninfringement, merchantability, or fitness for a particular purpose, and assumes no liability of any kind. All information is provided “AS IS.” This document is not an offer or a binding commitment by Ampere. Use of the products contemplated herein requires the subsequent negotiation and execution of a definitive agreement or is subject to Ampere’s Terms and Conditions for the Sale of Goods.

System configurations, components, software versions, and testing environments that differ from those used in Ampere’s tests may result in different measurements than those obtained by Ampere.

Price performance was calculated using Microsoft's Virtual Machines Pricing, in September of 2022. Refer to individual tests for more information.

©2022 Ampere Computing. All Rights Reserved. Ampere, Ampere Computing, Altra and the ‘A’ logo are all registered trademarks or trademarks of Ampere Computing. Arm is a registered trademark of Arm Limited (or its subsidiaries). All other product names used in this publication are for identification purposes only and may be trademarks of their respective companies.

Ampere Computing^® / 4655 Great America Parkway, Suite 601 / Santa Clara, CA 95054 / amperecomputing.com