Refactor Django on GCP learning path content for clarity and consistency

madeline-underwood · madeline-underwood · commit 347802b47113 · 2026-01-28T06:24:06.000Z
diff --git a/content/learning-paths/servers-and-cloud-computing/django-on-gcp/_index.md b/content/learning-paths/servers-and-cloud-computing/django-on-gcp/_index.md
@@ -1,5 +1,5 @@
 ---
-title: Deploy Django on Google Cloud C4A (Arm-based Axion VMs)
+title: Deploy Django on Arm-based Google Cloud C4A 
     
 minutes_to_complete: 60
 
diff --git a/content/learning-paths/servers-and-cloud-computing/django-on-gcp/background.md b/content/learning-paths/servers-and-cloud-computing/django-on-gcp/background.md
@@ -1,5 +1,5 @@
 ---
-title: Get started with Django on Google Axion C4A (Arm Neoverse V2)
+title: Get started with Django on Google Axion C4A 
 
 weight: 2
 
diff --git a/content/learning-paths/servers-and-cloud-computing/django-on-gcp/baseline.md b/content/learning-paths/servers-and-cloud-computing/django-on-gcp/baseline.md
@@ -6,7 +6,7 @@ weight: 6
 layout: learningpathall
 ---
 
-## Verify Django is working on your Arm-based VM
+## Verify Django installation
 
 In this section, you'll confirm that Django is installed correctly and can serve web requests on your Google Cloud C4A VM. You'll create a Django project, run the development server, and access it from your browser.
 
diff --git a/content/learning-paths/servers-and-cloud-computing/django-on-gcp/benchmarking.md b/content/learning-paths/servers-and-cloud-computing/django-on-gcp/benchmarking.md
@@ -14,6 +14,21 @@ This section guides you through benchmarking your Django web application using G
 
 To begin, if your Django development server is still running, stop it using `Ctrl + C`.
 
+Install ApacheBench to measure your application's performance under load.
+
+```bash
+sudo zypper install -y apache2-utils
+```
+
+Verify the installation:
+
+```bash
+ab -V
+```
+
+You should see the ApacheBench version information displayed.
+
+
 ApacheBench (`ab`) is a command-line tool that simulates multiple HTTP requests to measure web server performance. Install it using the following:
 
 ```bash
@@ -22,7 +37,7 @@ sudo zypper install -y apache2-utils
 
 ### Verify installation
 
-Confirm ApacheBench is correctly installed and available:
+Confirm ApacheBench is correctly installed and available.
 
 ```bash
 ab -V
@@ -34,19 +49,19 @@ The output displays the ApacheBench version.
 
 Before benchmarking your Django application, you need to install Gunicorn, a production-grade WSGI HTTP server. Gunicorn provides better performance characteristics than Django's development server and more accurately represents real-world deployment scenarios.
 
-### Install both Django and Gunicorn using pip:
+### Install both Django and Gunicorn using pip
 
 ```bash
 python3 -m pip install django gunicorn
 ```
 
-This installs Django and Gunicorn. Gunicorn is a high-performance WSGI HTTP server that handles multiple concurrent requests efficiently. Unlike Django's built-in development server, Gunicorn is designed for production workloads and provides the multi-worker architecture needed for accurate performance testing.
+This installs Django and Gunicorn. Gunicorn is a production-grade WSGI HTTP server that handles multiple requests at the same time. Unlike Django's built-in development server, Gunicorn uses multiple workers to process requests efficiently, which gives you more accurate performance measurements.
 
 ## Run Django with Gunicorn
 
-Your Django application runs with Gunicorn inside GKE. Gunicorn is deployed inside your Kubernetes Pods and exposed through a Kubernetes Service and LoadBalancer. The benchmark is executed against the external IP of the GKE service.
+Your Django application runs with Gunicorn inside GKE. The Gunicorn server is deployed inside your Kubernetes Pods and exposed through a Kubernetes Service and LoadBalancer. You run the benchmark against the external IP of the GKE service.
 
-{{% notice note %}}Ensure your GKE cluster and LoadBalancer are properly configured. If you haven't set up the cluster yet, refer to the previous sections for GKE deployment and service configuration. {{% /notice %}}
+{{% notice Note %}}Ensure your GKE cluster and LoadBalancer are properly configured. If you haven't set up the cluster yet, refer to the previous sections for GKE deployment and service configuration.{{% /notice %}}
 
 ## Run the benchmark
 
@@ -56,9 +71,16 @@ Use ApacheBench to test your Django server with simulated traffic:
 ab -n 5000 -c 100 http://<external_IP_of_the_GKE_service>/healthz/
 ```
 
-This sends 5000 requests using 100 concurrent connections to your Django REST endpoint exposed through the GKE LoadBalancer. After a few minutes, press CTRL-C to stop the benchmark.
+This command sends 5000 requests with 100 concurrent connections to your Django REST endpoint.
+
+Parameters explained:
+- `-n 5000`: total number of requests to send
+- `-c 100`: number of concurrent requests
+- `http://<external_IP_of_the_GKE_service>/healthz/`: your Django health check endpoint
+
+Replace `<external_IP_of_the_GKE_service>` with your actual GKE LoadBalancer IP address.
 
-The output is similar to:
+The benchmark runs for a few seconds and displays results similar to:
 
 ```output
 Server Software:        gunicorn
@@ -103,24 +125,32 @@ The ApacheBench output provides key performance metrics for evaluating your Djan
 
 ### Request handling metrics
 
-- Concurrency Level: number of simultaneous requests the benchmark sent (100 in this test)
-- Complete Requests: total successful requests processed (5000 in this test)
-- Failed Requests: number of errors or timeouts (0, indicating stable production-grade performance)
+Your benchmark captures three foundational indicators of request handling capacity:
+
+- Concurrency Level: simultaneous requests sent during the benchmark (100)
+- Complete Requests: total successful requests processed (5000)
+- Failed Requests: errors or timeouts encountered (0, indicating stable performance)
 
 ### Performance metrics
 
+Your Django application's performance under load is measured by three critical metrics:
+
 - Requests per Second: how many requests your server handles per second; higher values indicate better throughput (14,001.88 req/sec)
 - Time per Request (mean): average time to complete a single request (7.142 ms)
 - Time per Request (across concurrent): average latency when factoring in concurrent processing (0.071 ms), showing excellent parallel execution on Axion Arm cores
 
 ### Data transfer metrics
 
+The benchmark captures how efficiently your application transfers data across the network stack:
+
 - Total Transferred: all data sent and received, including HTTP headers (1,650,000 bytes)
 - HTML Transferred: actual response payload size (75,000 bytes)
 - Transfer Rate: network throughput in KB/sec (4512.32 KB/sec), indicating efficient networking through GKE LoadBalancer
 
 ### Timing breakdown
 
+The timing breakdown section provides detailed insight into how your application spends time processing each request:
+
 - Time Taken for Tests: total benchmark duration (0.357 seconds)
 - Connection Times: shows minimum, mean, median, and maximum times for connecting, processing, and waiting
 
@@ -134,33 +164,46 @@ Results from the run on the `Axion (C4A) Arm64 GKE nodes`:
 
 | **Parameter** | **Description** | **Value** |
 |--------------|------------------|-----------|
-| **Server Software** | Web server used for serving Django | gunicorn |
-| **Server Hostname** | External LoadBalancer IP | 34.132.110.81 |
-| **Server Port** | Port number for benchmark | 80 |
-| **Document Path** | Endpoint used for testing | /healthz/ |
-| **Document Length** | Size of each response | 15 bytes |
-| **Concurrency Level** | Number of concurrent requests | 100 |
-| **Time Taken for Tests** | Total time to complete all requests | 0.357 seconds |
-| **Complete Requests** | Total number of successful requests | 5000 |
-| **Failed Requests** | Number of failed requests | 0 |
-| **Total Transferred** | Total bytes transferred (including headers) | 1,650,000 bytes |
-| **HTML Transferred** | Total response body bytes | 75,000 bytes |
-| **Requests per Second (mean)** | Throughput - higher is better | **14,001.88 req/sec** |
-| **Time per Request (mean)** | Average time for each request | **7.142 ms** |
-| **Time per Request (across all concurrent requests)** | Average latency considering concurrency | **0.071 ms** |
-| **Transfer Rate** | Network throughput rate | **4512.32 KB/sec** |
+| **Server Software** | web server used for serving Django | gunicorn |
+| **Server Hostname** | external LoadBalancer IP | 34.132.110.81 |
+| **Server Port** | port number for benchmark | 80 |
+| **Document Path** | endpoint used for testing | /healthz/ |
+| **Document Length** | size of each response | 15 bytes |
+| **Concurrency Level** | number of concurrent requests | 100 |
+| **Time Taken for Tests** | total time to complete all requests | 0.357 seconds |
+| **Complete Requests** | total number of successful requests | 5000 |
+| **Failed Requests** | number of failed requests | 0 |
+| **Total Transferred** | total bytes transferred (including headers) | 1,650,000 bytes |
+| **HTML Transferred** | total response body bytes | 75,000 bytes |
+| **Requests per Second (mean)** | throughput - higher is better | **14,001.88 req/sec** |
+| **Time per Request (mean)** | average time for each request | **7.142 ms** |
+| **Time per Request (across all concurrent requests)** | average latency considering concurrency | **0.071 ms** |
+| **Transfer Rate** | network throughput rate | **4512.32 KB/sec** |
 | **p50 (Median Latency)** | 50% of requests completed within | **6 ms** |
 | **p90 Latency** | 90% of requests completed within | **11 ms** |
 | **p95 Latency** | 95% of requests completed within | **11 ms** |
 | **p99 Latency** | 99% of requests completed within | **28 ms** |
-| **Max Latency** | Longest request observed | **34 ms** |
+| **Max Latency** | longest request observed | **34 ms** |
 
 ## Key performance insights
 
 The benchmark results demonstrate the strength of running Django on Google Axion (Arm64) GKE:
 
-- Extreme Throughput: The cluster sustained 14,000+ requests per second through a public LoadBalancer → GKE → Gunicorn → Django → Cloud SQL → Redis stack.
-- Ultra-Low p95 Latency: Even at 100 concurrent users, 95% of all requests completed within 11 ms.
-- Production Stability: Zero failed requests confirms the platform is resilient under heavy parallel load.
-- Efficient Networking: Over 4.4 MB/sec of data transfer through the GKE LoadBalancer shows Arm-based networking is highly optimized.
-- Cloud-native Scalability: These results validate that Axion Arm64 nodes are well-suited for high-performance, horizontally scalable REST APIs in production.
+- Extreme Throughput: the cluster sustained 14,000+ requests per second through a public LoadBalancer → GKE → Gunicorn → Django → Cloud SQL → Redis stack.
+- Ultra-Low p95 Latency: even at 100 concurrent users, 95% of all requests completed within 11 ms.
+- Production Stability: zero failed requests confirms the platform is resilient under heavy parallel load.
+- Efficient Networking: over 4.4 MB/sec of data transfer through the GKE LoadBalancer shows Arm-based networking is highly optimized.
+- Cloud-native Scalability: these results validate that Axion Arm64 nodes are well-suited for high-performance, horizontally scalable REST APIs in production.
+
+## What you've accomplished and what's next
+
+In this section, you:
+- Installed and configured ApacheBench for load testing
+- Deployed Gunicorn as a production-grade WSGI server for Django
+- Executed a comprehensive benchmark against your GKE-hosted Django application
+- Analyzed performance metrics showing 14,000+ requests per second with sub-millisecond concurrent latency
+- Validated that Google Axion (Arm64) GKE delivers production-ready performance for Django workloads
+
+Your Django application is now proven to handle high-concurrency traffic efficiently on Arm-based infrastructure. You've established a performance baseline that demonstrates the scalability and reliability of running Django on Google Cloud's Axion processors with GKE, Cloud SQL, and Redis.
+
+You're ready to optimize further, scale your deployment, or integrate additional services into your cloud-native Django architecture.
diff --git a/content/learning-paths/servers-and-cloud-computing/django-on-gcp/containerization-and-deploy.md b/content/learning-paths/servers-and-cloud-computing/django-on-gcp/containerization-and-deploy.md
@@ -8,9 +8,10 @@ layout: learningpathall
 
 ## Containerize and deploy Django on Axion GKE
 
-This guide converts your Django REST API into a production-grade Arm64 container and deploys it on Axion-powered GKE.
+This section shows you how to package your Django REST API into a production-ready container and deploy it on GKE running Axion Arm64 processors.
+
+## Create a Docker image
 
-### Create Docker image
 This step packages your Django API and all its dependencies into a portable container image that can run on any Axion Arm64 node.
 
 Create a file called `requirements.txt` and insert the following:
@@ -35,7 +36,7 @@ CMD ["gunicorn","django_api.wsgi:application","--bind","0.0.0.0:8000","--workers
 
 This Dockerfile defines how to build your Django container for production deployment.
 
-### Build and push the image
+## Build and push the image
 
 Build the image on an Arm machine and push it to Artifact Registry, ensuring Kubernetes pulls an Arm-native image.
 
@@ -55,7 +56,7 @@ docker push us-central1-docker.pkg.dev/PROJECT_ID/django-arm/api:1.0
 
 The image is now stored in Artifact Registry and ready for deployment.
 
-### Deploy to GKE
+## Deploy to GKE
 
 Kubernetes Deployments define how many containers run and where. The nodeSelector forces pods onto Axion ARM64 nodes.
 
@@ -115,7 +116,8 @@ django-api-XXXXXX   1/1     Running   0          3h52m   10.0.1.9   gke-django-a
 
 The Django API is running as replicated containers on Axion Arm64 nodes.
 
-### Create a Kubernetes service (LoadBalancer)
+## Create a Kubernetes service (LoadBalancer)
+
 A Service exposes your pods to the internet using **Google Cloud’s managed load balancer**.
 
 Create `k8s/service.yaml`:
@@ -140,7 +142,7 @@ Apply the service configuration:
 kubectl apply -f k8s/service.yaml
 ```
 
-### Validate public access
+## Validate the service
 
 ```bash
 kubectl get svc django-api
@@ -153,7 +155,7 @@ django-api   LoadBalancer   34.118.226.245   34.45.23.92   80:31700/TCP   3h57m
 
 Wait until the `EXTERNAL-IP` field is populated before proceeding.
 
-### Validate public access
+## Test the application
 
 Open the following URL in browser:
 
diff --git a/content/learning-paths/servers-and-cloud-computing/django-on-gcp/django_application.md b/content/learning-paths/servers-and-cloud-computing/django-on-gcp/django_application.md
@@ -8,9 +8,9 @@ layout: learningpathall
 
 ## Django REST API with PostgreSQL and Redis
 
-This guide walks you through building a production-ready Django REST API that connects to PostgreSQL for data and Redis for caching.
+In this section you'll build a Django REST API that uses PostgreSQL for database storage and Redis for caching. This matches how production applications are typically structured.
 
-### Create Django project
+## Create a Django project
 
 Set up a clean Python virtual environment and install all runtime dependencies required for Django, PostgreSQL, Redis, and production serving with Gunicorn.
 
@@ -37,7 +37,7 @@ django-admin startapp api
 
 The Django project structure is ready with all required libraries for database, cache, and API support.
 
-### Enable Django apps
+## Enable Django apps
 
 Enable the REST framework and API app by editing `django_api/settings.py`. Add 'rest_framework' and 'api' to INSTALLED_APPS, set DEBUG to False, and add '*' to ALLOWED_HOSTS: 
 
@@ -60,7 +60,7 @@ INSTALLED_APPS = [
 
 Django is configured to run as an API server.
 
-### Configure PostgreSQL and Redis
+## Configure PostgreSQL and Redis
 
 This step connects Django to external managed services instead of local SQLite. This mirrors how real production systems operate.
 
@@ -96,7 +96,8 @@ Edit the above addition and set `REDIS_IP` to the actual IP address that you sav
 
 The application is configured to use PostgreSQL and Redis.
 
-### Migrate the database
+## Migrate the database
+
 Django creates tables, metadata, and user models inside PostgreSQL.
 
 ```bash
@@ -106,7 +107,7 @@ python manage.py createsuperuser
 
 The PostgreSQL instance contains all Django system tables.
 
-### Create a health API endpoint
+## Create a health API endpoint
 
 A health endpoint allows Kubernetes and load balancers to verify if the service is running.
 
@@ -134,7 +135,8 @@ urlpatterns = [
 
 The health endpoint is configured.
 
-### Validate locally
+## Validate locally
+
 Before containerizing or deploying, validate that everything works end-to-end.
 
 ```bash
diff --git a/content/learning-paths/servers-and-cloud-computing/django-on-gcp/firewall_setup.md b/content/learning-paths/servers-and-cloud-computing/django-on-gcp/firewall_setup.md
@@ -19,9 +19,9 @@ For support on GCP setup, see the Learning Path [Getting started with Google Clo
 
 Navigate to the Google Cloud Console and create a new firewall rule:
 
-- Go to the **Google Cloud Console**
-- Select **VPC network** > **Firewall**
-- Select **Create firewall rule**
+- Go to the **Google Cloud Console**.
+- Select **VPC network** > **Firewall**.
+- Select **Create firewall rule**.
 
 ![Screenshot of the Google Cloud Console showing the Firewall section. The Create firewall rule button is prominently displayed at the top of the page#center](images/firewall-rule.png "Google Cloud Console Firewall page")
 
diff --git a/content/learning-paths/servers-and-cloud-computing/django-on-gcp/installation.md b/content/learning-paths/servers-and-cloud-computing/django-on-gcp/installation.md
@@ -20,7 +20,7 @@ sudo zypper update -y
 sudo zypper install -y curl git tar gzip
 ```
 
-### Install Python 3.11
+## Install Python 3.11
 
 Install Python 3.11:
 
@@ -47,10 +47,6 @@ pip 22.3.1 from /usr/lib/python3.11/site-packages/pip (python 3.11)
 
 The Google Cloud CLI is required to authenticate with GCP and allow your Django application VM to interact with Google Cloud services such as GKE, Cloud SQL, Artifact Registry, Memorystore, and to build, deploy, and operate the Django platform.
 
-### Install Google Cloud SDK (gcloud)
-
-The Google Cloud SDK is required to create and manage GKE clusters.
-
 Download and extract the Google Cloud SDK:
 
 ```bash
@@ -70,7 +66,7 @@ After installation completes, exit and reconnect to apply the PATH changes:
 exit
 ```
 
-### Initialize gcloud
+## Initialize gcloud
 
 Authenticate and configure the Google Cloud CLI:
 
@@ -80,7 +76,7 @@ gcloud init
 
 During initialization, select **Login with a new account**. You'll be prompted to authenticate using your browser and receive an auth code to copy back. Select the project you want to use and choose default settings when unsure.
 
-### Verify authentication
+## Verify authentication
 
 ```bash
 gcloud auth list
@@ -144,4 +140,4 @@ In this section, you installed:
 - Python 3.11 with a virtual environment
 - Django and Gunicorn for web application development
 
-Next, you'll verify Django is working by creating a basic project and running the development server.
+Next, you'll verify Django is working by creating a basic project and running the development server.
diff --git a/content/learning-paths/servers-and-cloud-computing/django-on-gcp/instance.md b/content/learning-paths/servers-and-cloud-computing/django-on-gcp/instance.md
diff --git a/content/learning-paths/servers-and-cloud-computing/django-on-gcp/overview-and-infrastructure.md b/content/learning-paths/servers-and-cloud-computing/django-on-gcp/overview-and-infrastructure.md
