Update Node.js GCP learning path content

Author: madeline-underwood

content/learning-paths/servers-and-cloud-computing/node-js-gcp/baseline.md

@@ -1,39 +1,41 @@
 ---
-title: Node.js baseline testing on Google Axion C4A Arm Virtual machine
+title: Validate Node.js baseline on Google Axion C4A Arm virtual machine
 weight: 5
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
+## Validate Node.js installation with a baseline test
 
-Since Node.js has been successfully installed on your GCP C4A Arm virtual machine, please follow these steps to make sure that it is running.
+Confirm that your Node.js installation works as expected before benchmarking performance on your Arm-based VM. Run these baseline tests to verify that Node.js is installed correctly and can execute JavaScript code and serve HTTP requests. Catch setup issues early and ensure your environment is ready for further testing.
 
-## Validate Node.js installation with a baseline test
+## Run a simple REPL test
 
-### 1. Run a Simple REPL Test
-The Node.js REPL (Read-Eval-Print Loop) allows you to run JavaScript commands interactively.
+Start the Node.js REPL (Read-Eval-Print Loop) to run JavaScript commands interactively:
 
 ```console
 node
 ```
-Inside the REPL, type:
+
+Type the following command inside the REPL:
 
 ```console
 console.log("Hello from Node.js");
 ```
-You should see an output similar to:
+
+The output is similar to:
 
 ```output
 Hello from Node.js
 undefined
 ```
-This confirms that Node.js can execute JavaScript commands successfully.   Please now press "Ctrl-D" to exit node. 
 
-### 2. Test a Basic HTTP Server
-You can now create a small HTTP server to validate that Node.js can handle web requests.
+This confirms that Node.js can execute JavaScript commands successfully. Press "Ctrl-D" to exit node.
+
+## Test a basic HTTP server
 
-Use a text editor to create a file named `app.js` with the code below: 
+Create a file named `app.js` with the following code to validate that Node.js can handle web requests:
 
 ```javascript
 const http = require('http');
@@ -47,41 +49,46 @@ server.listen(80, '0.0.0.0', () => {
   console.log('Server running at http://0.0.0.0:80/');
 });
 ```
- - This server listens on port 80.
- - Binding to 0.0.0.0 allows connections from any IP, not just localhost.
 
-Next, we run the HTTP server in the background via sudo:
+The server listens for incoming connections on port 80, which is the default port for HTTP traffic. By binding to the IP address 0.0.0.0, the server accepts connections from any network interface, not just from localhost. This configuration enables access from other devices on the network.
+
+Run the HTTP server in the background using sudo:
 
 ```console
 export MY_NODE=`which node`
 sudo ${MY_NODE} app.js &
 ```
-You should see an output similar to:
+
+The expected output is:
 
 ```output
 Server running at http://0.0.0.0:80/
 ```
-#### Test Locally with Curl
+
+## Test locally with curl
+
+Run the following command to test the server locally:
 
 ```console
 curl http://localhost:80
 ```
 
-You should see an output similar to:
+The expected output is:
 
 ```output
 Baseline test successful!
 ```
 
-#### Test from a Browser
-Also, you can access it from the browser with your VM's public IP. Run the following command to print your VM’s public URL, then open it in a browser:
+## Test from a browser
+
+Print your VM’s public URL and open it in a browser:
 
 ```console
 echo "http://$(curl -s ifconfig.me):80/"
 ```
 
 You should see the following message in your browser, confirming that your Node.js HTTP server is running successfully:
 
-![Node.js Browser alt-text#center](images/node-browser.png)
+![Screenshot showing the browser displaying 'Baseline test successful!' from the Node.js HTTP server running on a Google Axion C4A Arm VM. alt-text#center](images/node-browser.png "Browser displaying baseline test successful dialogue message")
 
-This verifies the basic functionality of the Node.js installation before proceeding to the benchmarking.
+You have now validated that Node.js is working correctly on your Arm VM. Proceed to benchmarking and performance testing.

content/learning-paths/servers-and-cloud-computing/node-js-gcp/benchmarking.md

@@ -1,44 +1,53 @@
 ---
-title: Node.js Benchmarking
+title: Benchmark Node.js performance with Autocannon on Arm and x86_64
 weight: 6
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
-## Node.js Benchmarking by Autocannon
+## Benchmark Node.js with Autocannon
 
-After validating that Node.js is installed and your HTTP server is running, you can benchmark it using **Autocannon**.
+After validating that Node.js is installed and your HTTP server is running, you can benchmark it using Autocannon. You'll use Autocannon to run a series of tests, analyze the results, and identify areas for optimization. Benchmarking on Arm64 provides valuable insights into how Node.js applications scale and perform in cloud environments, helping you make informed decisions about deployment and resource allocation.
 
 ## Install Autocannon
-**Autocannon** is a fast HTTP/1.1 benchmarking tool for Node.js, used to measure server throughput, latency, and request handling under concurrent load.
+
+Autocannon is a fast HTTP/1.1 benchmarking tool for Node.js, used to measure server throughput, latency, and request handling under concurrent load. To install Autocannon, run this command:
 
 ```console
 npm install -g autocannon
 ```
 
-## Start Your Node.js HTTP Server
+## Start the Node.js HTTP server
 
-If your sample HTTP server is not already running from the last section, you can start it by typing:
+If your sample HTTP server is still running from the last section, you can start it by using this command:
 ```console
 export MY_NODE=`which node`
 sudo ${MY_NODE} app.js &
 ```
 
-Server should be listening on port 80 in the background:
+The server should be listening on port 80 in the background:
 
 ```output
 Server running at http://0.0.0.0:80/
 ```
 
-## Run a Basic Benchmark (Local)
+## Run a local Node.js benchmark with Autocannon
+
+Now run a local Node.js benchmark with Autocannon:
 
 ```console
 autocannon -c 100 -d 10 http://localhost:80
 ```
-- `-c 100` → 100 concurrent connections
-- `-d 10` → duration 10 seconds
-- URL → endpoint to test
+{{% notice Tip %}}
+These options specify how the benchmarking tool runs the test:
+
+- The `-c 100` flag sets the number of concurrent connections to one hundred, simulating multiple users accessing the endpoint at the same time.
+- The `-d 10` flag sets the test duration to ten seconds, so the tool sends requests for that period.
+- The URL is the endpoint you're measuring, which could be a web service or API running on your Arm server.
+
+This configuration helps you evaluate how your application performs under load on Arm platforms.
+{{% /notice %}}
 
 You should see an output similar to:
 ```output
@@ -65,48 +74,52 @@ Req/Bytes counts sampled once per second.
 707k requests in 10.02s, 137 MB read
 ```
 
-## Understanding Node.js benchmark metrics and results with Autocannon
+## Interpret the Autocannon benchmark metrics
 
-- **Avg (Average Latency)** → The mean time it took for requests to get a response.
-- **Stdev (Standard Deviation)** → How much individual request times vary around the average. Smaller numbers mean more consistent response times.
-- **Min (Minimum Latency)** → The fastest request observed during the test.
+Now have a look at the Autocannon benchmark metrics to get a sense of how Node.js performed. Here is an explanation of the metrics and what they mean:
+
+- The average latency (Avg) shows the mean time it takes for each request to receive a response from the server. 
+- Standard deviation (Stdev) indicates how much the response times vary around the average; lower values mean the server responds more consistently. 
+- The minimum latency (Min) represents the fastest response recorded during the benchmark, highlighting the best-case performance for individual requests.
+
+## Review Node.js benchmark results on x86_64
 
-### Benchmark summary on x86_64
 To compare the benchmark results, the following results were collected by running the same benchmark on a `x86 - c4-standard-4` (4 vCPUs, 15 GB Memory) x86_64 VM in GCP, running SUSE:
 
-Latency (ms):
+### Latency results (ms):
 
 | Metric   | 2.5% | 50% (Median) | 97.5% | 99% | Avg    | Stdev  | Max   |
 |----------|------|--------------|-------|-----|--------|--------|-------|
 | Latency  | 0    | 1            | 2     | 2   | 0.73   | 0.87   | 104   |
 
-Throughput:
+### Throughput results:
 
 | Metric     | 1%     | 2.5%   | 50%     | 97.5%   | Avg      | Stdev     | Min     |
 |------------|--------|--------|---------|---------|----------|-----------|---------|
 | Req/Sec    | 70,143 | 70,143 | 84,479  | 93,887  | 84,128   | 7,547.18  | 70,095 |
 | Bytes/Sec  | 13.6 MB| 13.6 MB| 16.4 MB | 18.2 MB | 16.3 MB  | 1.47 MB   | 13.6 MB|
 
-### Benchmark summary on Arm64
-Results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE):
+## Review Node.js benchmark results on Arm64
+
+Here are the results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE):
 
-Latency (ms):
+### Latency results (ms):
 
 | Metric   | 2.5% | 50% (Median) | 97.5% | 99% | Avg  | Stdev | Max  |
 |----------|------|--------------|-------|-----|------|-------|------|
 | Latency  | 1    | 1            | 3     | 3   | 1.2  | 0.62  | 24   |
 
-Throughput:
+### Throughput results:
 
 | Metric     | 1%     | 2.5%   | 50%     | 97.5%   | Avg      | Stdev    | Min     |
 |------------|--------|--------|---------|---------|----------|----------|---------|
 | Req/Sec    | 45,279 | 45,279 | 54,719  | 55,199  | 53,798.4 | 2,863.96 | 45,257 |
 | Bytes/Sec  | 8.78 MB| 8.78 MB| 10.6 MB | 10.7 MB | 10.4 MB  | 557 kB   | 8.78 MB |
 
-## Node.js performance benchmarking comparison on Arm64 and x86_64
-When you compare the benchmarking results, you will notice that on the Google Axion C4A Arm-based instances:
+## Evaluate Node.js performance on Arm64
 
-- Average latency is very low (~1.2 ms) with consistent response times.  
-- Maximum latency spikes are rare, reaching up to 24 ms.  
-- The server handles high throughput, averaging ~53,798 requests/sec.  
-- Data transfer rate averages 10.4 MB/sec, demonstrating efficient performance under load.
+Now that you have the benchmarking results, you can see how Node.js performs on Arm64: 
+- The average latency is low, around 1.2 ms, which means your server responds quickly to requests.
+- Response times are consistent, with only occasional spikes up to 24 ms.
+- The server processes a high volume of traffic, averaging about 53,800 requests per second.
+- Data transfer rates are efficient, averaging 10.4 MB per second during the benchmark.

content/learning-paths/servers-and-cloud-computing/node-js-gcp/installation.md

@@ -6,10 +6,10 @@ weight: 4
 layout: learningpathall
 ---
 
-## Overview
-This section shows you how to install Node.js using Node Version Manager (NVM). NVM lets you choose which Node.js version to use and handles the download and installation for you. You’ll use official Node.js packages, making setup simple and reliable.
-
 ## Install Node Version Manager (NVM)
+To install Node.js on your Arm-based VM, use Node Version Manager (NVM). NVM lets you select and manage different Node.js versions easily. By using official Node.js packages, you'll get a reliable and straightforward setup.
+
+
 First, use this command to download and install NVM into your VM instance:
 
 ```console