Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,19 +1,15 @@
---
title: Deploy Redis for data searching on Google Cloud C4A (Arm-based Axion VMs)

draft: true
cascade:
draft: true
title: Deploy Redis for data searching on Google Cloud C4A

minutes_to_complete: 30

who_is_this_for: This learning path is intended for software developers deploying and optimizing Redis-based data searching workloads on Linux/Arm64 environments, specifically using Google Cloud C4A virtual machines powered by Axion processors.
who_is_this_for: This is an introductory topic for developers deploying and optimizing Redis-based data searching workloads on Linux/Arm64 environments, specifically using Google Cloud C4A virtual machines powered by Axion processors.

learning_objectives:
- Provision an Arm-based SUSE SLES virtual machine on Google Cloud (C4A with Axion processors)
- Install Redis on a SUSE Arm64 (C4A) instance
- Verify Redis functionality by running the server and performing baseline data insertion and retrieval tests on the Arm64 VM
- Measure Redis SET (write) and GET (read) performance using the official redis-benchmark tool to evaluate throughput and latency on Arm64 (Aarch64)
- Measure Redis SET (write) and GET (read) performance using the official redis-benchmark tool to evaluate throughput and latency on Arm64 (AArch64)

prerequisites:
- A [Google Cloud Platform (GCP)](https://cloud.google.com/free) account with billing enabled
Expand Down
Original file line number Diff line number Diff line change
@@ -1,25 +1,25 @@
---
title: Getting started with Redis on Google Axion C4A (Arm Neoverse-V2)
title: Get started with Redis on Google Axion C4A

weight: 2

layout: "learningpathall"
---

## Google Axion C4A Arm instances in Google Cloud
## Explore Google Axion C4A Arm instances

Google Axion C4A is a family of Arm-based virtual machines built on Googles custom Axion CPU, which is based on Arm Neoverse-V2 cores. Designed for high-performance and energy-efficient computing, these virtual machines offer strong performance for modern cloud workloads such as CI/CD pipelines, microservices, media processing, and general-purpose applications.
Google Axion C4A is a family of Arm-based virtual machines built on Google's custom Axion CPU, based on Arm Neoverse-V2 cores. These virtual machines deliver strong performance for modern cloud workloads such as CI/CD pipelines, microservices, media processing, and general-purpose applications.

The C4A series provides a cost-effective alternative to x86 virtual machines while leveraging the scalability and performance benefits of the Arm architecture in Google Cloud.
The C4A series provides a cost-effective alternative to x86 virtual machines while leveraging the scalability and performance benefits of Arm architecture in Google Cloud.

To learn more about Google Axion, refer to the [Introducing Google Axion Processors, our new Arm-based CPUs](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu) blog.
Learn more about Google Axion from the Google blog [Introducing Google Axion Processors, our new Arm-based CPUs](https://cloud.google.com/blog/products/compute/introducing-googles-new-arm-based-cpu).

## Redis
## Explore Redis

[Redis](https://redis.io/) is an open-source, **in-memory data structure store** developed under the [Redis project](https://redis.io/). It is used as a **database**, **cache**, and **message broker**, supporting a variety of data structures such as **strings**, **hashes**, **lists**, **sets**, and **sorted sets**.
[Redis](https://redis.io/) is an open-source, in-memory data structure store developed under the [Redis project](https://redis.io/). It is used as a database, cache, and message broker, supporting a variety of data structures such as strings, hashes, lists, sets, and sorted sets.

Redis is designed for **high performance**, **low latency**, and **high throughput**, making it ideal for real-time applications. It supports **persistence**, **replication**, **Lua scripting**, **transactions**, and **high availability** through Redis Sentinel and **automatic partitioning** with Redis Cluster.
Redis is designed for high performance, low latency, and high throughput, making it ideal for real-time applications. It supports persistence, replication, Lua scripting, transactions, and high availability through Redis Sentinel and automatic partitioning with Redis Cluster.

Redis is widely adopted for **caching**, **session management**, **real-time analytics**, **pub/sub messaging**, and **leaderboards** in gaming and web applications. It integrates seamlessly with programming languages like **Python**, **Java**, **Go**, and **Node.js**.
Redis is widely adopted for caching, session management, real-time analytics, pub/sub messaging, and leaderboards in gaming and web applications. It integrates seamlessly with programming languages like Python, Java, Go, and Node.js.

To learn more, visit the [Redis official website](https://redis.io/) and explore the [documentation](https://redis.io/docs/latest/).
To learn more, visit the [Redis website](https://redis.io/) and explore the [Redis documentation](https://redis.io/docs/latest/).
Original file line number Diff line number Diff line change
@@ -1,64 +1,67 @@
---
title: Redis Baseline Testing on Google Axion C4A Arm Virtual Machine
title: Test Redis
weight: 5

### FIXED, DO NOT MODIFY
layout: learningpathall
---

## Redis Baseline Testing on GCP SUSE VMs
This section performs baseline testing for Redis running on a GCP SUSE Arm64 VM, focusing on data insertion, retrieval, and search performance.
## Perform Redis baseline testing on GCP SUSE VMs
This section shows you how to perform baseline testing for Redis running on a GCP SUSE Arm64 VM, focusing on data insertion, retrieval, and search performance.

### Prerequisites
This command launches the Redis server process in the background. It allows you to run subsequent commands in the same terminal session while Redis continues running.
Start the Redis service in the background:

Start the Redis service:

```console
redis-server &
```

**Check if Redis is active and responding to commands:**

The redis-cli ping command sends a simple health check request to the Redis server. A PONG response confirms that the server is running correctly and the client can communicate with it.
Check if Redis is active and responding to commands:
```console
redis-cli ping
```

output:
The output is similar to:

```output
PONG
```

### Insert Sample Data
These steps populate the Redis database with a sample dataset to validate insertion performance and data persistence. You will create 10,000 key-value pairs using a simple shell loop and verify that the data has been successfully stored.
## Insert sample data

Populate the Redis database with a sample dataset to validate insertion performance and data persistence. You create 10,000 key-value pairs using a simple shell loop and verify that the data has been successfully stored.

Use `redis-cli` to insert 10,000 sample key-value pairs:

Use `redis-cli` to insert **10,000 sample key-value pairs**:
```console
for i in $(seq 1 10000); do
redis-cli SET key:$i "value-$i" > /dev/null
done
```
- This command iterates through numbers **1 to 10,000**, setting each as a Redis key in the format `key:<number>` with the corresponding value `"value-<number>"`.
- The `> /dev/null` part suppresses command output to make the insertion process cleaner and faster.
- The `> /dev/null` part suppresses command output to make the insertion process cleaner and faster.

**Verify Data Storage Count:**

The `DBSIZE` command returns the total number of keys currently stored in the Redis database.
Verify data storage count:

```console
redis-cli DBSIZE
```

The output is similar to:

```output
(integer) 10000
```
Seeing `(integer) 10000` confirms that all key-value pairs were inserted successfully.

**Verify Sample Data Retrieval**
This confirms that all key-value pairs were inserted successfully.

### Verify sample data retrieval

Fetch one of the inserted keys to confirm data correctness:

Verify sample data retrieval:
```console
redis-cli GET key:5000
```
Expand All @@ -71,11 +74,12 @@ You should see an output similar to:
"value-5000"
```

### Perform Basic Data Search Tests
## Perform basic data search tests
This step verifies Redis’s ability to retrieve specific data efficiently using unique keys. The `GET` command fetches the value associated with a given key from Redis.

You can test this by retrieving a known key-value pair:
Verify Redis's ability to retrieve specific data efficiently using unique keys. The `GET` command fetches the value associated with a given key from Redis.

Test this by retrieving a known key-value pair:
```console
redis-cli GET key:1234
```
Expand All @@ -87,17 +91,16 @@ You should see an output similar to:
```
This confirms that Redis is storing and retrieving data correctly from memory.

### Search for Multiple Keys Using Pattern Matching
## Search for multiple keys using pattern matching
This test demonstrates how Redis can locate multiple keys that match a pattern, useful for exploratory queries or debugging.

Use the `KEYS` command to search for keys matching a pattern:

```console
redis-cli KEYS "key:1*"
```
`KEYS` is fast but **blocks the server** when handling large datasets, so it’s not recommended in production.

You should see an output similar to:
The output is similar to:

```output
1) "key:1392"
Expand All @@ -112,8 +115,11 @@ You should see an output similar to:
..........
```

### Production-Safe Searching with SCAN
This step introduces a production-friendly method for iterating through keys without blocking Redis operations.
{{% notice Note %}}
`KEYS` is fast but blocks the server when handling large datasets, so it's not recommended in production.
{{% /notice %}}

## Production-safe searching with SCAN

Use the `SCAN` command for larger datasets — it is non-blocking and iterates safely.

Expand All @@ -137,8 +143,9 @@ You should see an output similar to:
Redis will return a cursor value (for example, `9792`).
Continue scanning by reusing the cursor until it returns `0`, meaning the iteration is complete.

### Measure Data Retrieval Performance
This step measures how quickly Redis can retrieve a single key from memory, helping to establish a baseline for data access latency on the Arm-based VM.
## Measure data retrieval performance

Measure how quickly Redis can retrieve a single key from memory, helping to establish a baseline for data access latency on the Arm-based VM.

**Time Single Key Lookup**: Redis operations are extremely fast since data is stored in-memory. To quantify this, the Unix `time` command is used to measure the latency of retrieving a single key using `redis-cli`.

Expand Down
Original file line number Diff line number Diff line change
@@ -1,44 +1,45 @@
---
title: Redis Benchmarking
title: Benchmark Redis
weight: 6

### FIXED, DO NOT MODIFY
layout: learningpathall
---

## Benchmark Redis using redis-benchmark

## Redis Benchmarking by redis-benchmark
The `redis-benchmark` tool is an official performance testing utility for Redis. It helps measure to throughput (requests per second) and latency (response delay) across different workloads.
The `redis-benchmark` tool is an official performance testing utility for Redis. It measures throughput (requests per second) and latency (response delay) across different workloads.

### Prerequisites
Ensure Redis server is running and accessible:

Before running benchmarks, verify that Redis is running and accessible:

```console
redis-cli ping
```

If you do not see a "PONG" response, please start redis:
If you don't see a `PONG` response, start Redis:

```console
redis-server &
redis-cli ping
```

### Benchmark SET (Write Performance)
The `SET` benchmark helps validate Redis’s ability to handle high insertion rates efficiently on Arm-based servers.
### Benchmark SET (write performance)

The following command benchmarks data insertion performance:
Benchmark data insertion performance:

```console
redis-benchmark -t set -n 100000 -c 50
```
**Explanation:**

- `-t set`: Runs the benchmark only for **SET** operations.
- `-n 100000`: Performs **100,000 total requests**.
- `-c 50`: Simulates **50 concurrent clients**.
This command:

- Runs the benchmark for SET operations only (`-t set`)
- Performs 100,000 total requests (`-n 100000`)
- Simulates 50 concurrent clients (`-c 50`)

You should see an output similar to:
The output is similar to:

```output
====== SET ======
Expand Down Expand Up @@ -85,19 +86,20 @@ Summary:
0.170 0.056 0.167 0.183 0.191 1.095
```

### Benchmark GET (Read/Search Performance)
Now test data retrieval performance separately.
### Benchmark GET (read performance)

Test data retrieval performance:

```console
redis-benchmark -t get -n 100000 -c 50
```
**Explanation:**

- `-t get`: Runs the benchmark only for **GET** operations.
- `-n 100000`: Executes **100,000 total requests**.
- `-c 50`: Simulates **50 concurrent clients** performing reads.
Parameters:

- `-t get`: Runs the benchmark only for GET operations.
- `-n 100000`: Executes 100,000 total requests.
- `-c 50`: Simulates 50 concurrent clients performing reads.

You should see an output similar to:
The output is similar to:

```output
====== GET ======
Expand Down Expand Up @@ -141,26 +143,24 @@ Summary:
0.169 0.048 0.167 0.183 0.191 0.807
```

### Benchmark Metrics Explanation
## Interpret the benchmark metrics

- **Throughput:** Number of operations (requests) Redis can process per second.
- **Latency:** Latency reflects the time it takes for Redis to complete a single request, measured in milliseconds (ms).
- **avg:** Average time taken to process a request across the entire test.
- **min:** Fastest observed response time (best case).
- **p50:** Median latency — 50% of requests completed faster than this value.
- **p95:** 95th percentile — 95% of requests completed faster than this value.
- **p99:** 99th percentile — shows near worst-case latency, key for reliability analysis.
- **max:** Slowest observed response time (worst case).

### Benchmark summary
Results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE Enterprise Server):
The following table summarizes the benchmark results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE Enterprise Server):

| Operation | Total Requests | Concurrent Clients | Avg Latency (ms) | Min (ms) | P50 (ms) | P95 (ms) | P99 (ms) | Max (ms) | Throughput (req/sec) | Description |
|------------|----------------|--------------------|------------------|-----------|-----------|-----------|-----------|-----------|-----------------------|--------------|
| SET | 100,000 | 50 | 0.170 | 0.056 | 0.167 | 0.183 | 0.191 | 1.095 | 149,700.61 | Measures Redis write performance using SET command |
| GET | 100,000 | 50 | 0.169 | 0.048 | 0.167 | 0.183 | 0.191 | 0.807 | 150,375.94 | Measures Redis read performance using GET command |

- **High Efficiency:** Redis achieved over **150K ops/sec** on both read and write workloads, showcasing strong throughput on **Arm64 (C4A)** architecture.
- **Low Latency:** Average latency remained around **0.17 ms**, demonstrating consistent response times under concurrency.
- **Balanced Performance:** Both **SET** and **GET** operations showed nearly identical performance, indicating excellent CPU and memory optimization on **Arm64**.
- **Energy-Efficient Compute:** The **Arm-based C4A VM** delivers competitive performance-per-watt efficiency, ideal for scalable, sustainable Redis deployments.
Redis demonstrated excellent performance on the Arm64-based C4A VM, achieving over 150K operations per second for both read and write workloads with an average latency of approximately 0.17 ms. Both SET and GET operations showed nearly identical performance characteristics, indicating efficient CPU and memory optimization on the Arm architecture. The Arm-based C4A VM delivers competitive performance-per-watt efficiency, making it ideal for scalable, sustainable Redis deployments.

## What you've accomplished and what's next

In this section, you:
- Benchmarked Redis SET operations, achieving over 149K requests per second with 0.170 ms average latency
- Benchmarked Redis GET operations, achieving over 150K requests per second with 0.169 ms average latency
- Verified that Redis performs efficiently on Google Axion C4A Arm instances

You've successfully benchmarked Redis on Google Cloud's C4A Arm-based virtual machines, demonstrating strong performance for in-memory data operations.

For next steps, consider exploring Redis Cluster for distributed deployments, implementing persistence strategies for production workloads, or testing more advanced data structures like sorted sets and streams. You can also compare performance across different C4A machine types to optimize cost and performance for your specific use case.
Loading