Merge pull request #3451 from anupras-mohapatra-arm/servers-and-cloud-computing

NGINX tuning LP review

Author: jasonrandrews

content/learning-paths/servers-and-cloud-computing/nginx_tune/_index.md

@@ -15,11 +15,58 @@ learning_objectives:
 prerequisites:
     - A cloud or bare-metal installation of an NGINX file server, reverse proxy, or API gateway.
     - A repeatable HTTP workload or load test that you can run before and after tuning.
-    - If you do not already have an NGINX setup, review [Learn how to deploy NGINX](/learning-paths/servers-and-cloud-computing/nginx/).
+    - If you don't already have an NGINX setup, see [Learn how to deploy NGINX](/learning-paths/servers-and-cloud-computing/nginx/).
+
+# START generated_summary_faq
+generated_summary_faq:
+  template_version: summary-faq-v3
+  generated_at: '2026-06-30T15:49:37Z'
+  generator: ai
+  ai_assisted: true
+  ai_review_required: true
+  model: gpt-5
+  prompt_template: summary-faq-v3
+  source_hash: 39f9323dac9bd7f5480e501ad8fd93d2d9999c420ed1c2eb45eba2ccb3be63ad
+  summary_generated_at: '2026-06-30T15:49:37Z'
+  summary_source_hash: 39f9323dac9bd7f5480e501ad8fd93d2d9999c420ed1c2eb45eba2ccb3be63ad
+  faq_generated_at: '2026-06-30T15:49:37Z'
+  faq_source_hash: 39f9323dac9bd7f5480e501ad8fd93d2d9999c420ed1c2eb45eba2ccb3be63ad
+  summary: >-
+    You'll learn how to tune NGINX on Arm-based platforms using a measurement-first
+    workflow. Using a baseline, you'll iteratively adjust Linux network stack parameters and
+    evaluate compiler and library choices such as OpenSSL, PCRE, and zlib. You'll review tuned configuration examples and guidance for sizing directives to refine configurations
+    for static file serving, reverse proxy, and API gateway scenarios. You'll also learn about `wrk`
+    as an option for generating traffic and reporting throughput and latency on NGINX. By the end, you'll use `wrk` to compare before-and-after results and verify the impact of each tuning change.
+  faqs:
+  - question: How do I know whether a tuning change improved performance?
+    answer: >-
+      Re-run the same repeatable workload and compare throughput and latency before and after
+      the change. Adjust one parameter at a time or use a designed experiment so results are attributable
+      to specific settings.
+  - question: Where do I change Linux network parameters when tuning?
+    answer: >-
+      Modify settings in /etc/sysctl.conf or use the sysctl command. Refer to the Linux kernel
+      sysctl documentation, and treat these changes as part of the same measurement process used
+      for NGINX directives.
+  - question: Do I need to use wrk if I already have a load test?
+    answer: >-
+      No. If you already have a repeatable HTTP workload, use that. wrk is provided as a starting point
+      only when you don't already have an established test method.
+  - question: When tuning the reverse proxy or API gateway, what should I reuse from the static
+      file server configuration?
+    answer: >-
+      Use the same top-level nginx.conf from the static file server section. Then apply the tuned
+      reverse proxy and API gateway configuration and validate the result with repeatable measurements.
+  - question: How do compiler, OpenSSL, PCRE, and zlib choices factor into tuning?
+    answer: >-
+      Evaluate these choices as part of your experiments because they can affect NGINX performance.
+      Compare alternatives using the same workload and interpret results alongside your NGINX
+      and kernel changes.
+# END generated_summary_faq
 
 author: Julio Suarez
 
-generate_summary_faq: true
+generate_summary_faq: false
 rerun_summary: false
 rerun_faqs: false
 
@@ -73,3 +120,4 @@ weight: 1                       # _index.md always has weight of 1 to order corr
 layout: "learningpathall"       # All files under learning paths have this same wrapper
 learning_path_main_page: "yes"  # This should be surfaced when looking for related content. Only set for _index.md of learning path content.
 ---
+

content/learning-paths/servers-and-cloud-computing/nginx_tune/before_and_after.md

@@ -1,21 +1,21 @@
 ---
-title: "Measure NGINX tuning impact"
+title: Measure the impact of NGINX tuning 
 description: Learn how to approach NGINX performance tuning as a measurement-driven process and compare baseline results with tuned results.
 weight: 2
 layout: "learningpathall"
 ---
 
 ## About performance tuning
 
-Performance tuning is most useful when you treat it as a measurement process, not a fixed checklist. You can tune by changing one parameter at a time, running a designed experiment, comparing profiles, or using automation and AI-assisted tools to explore a larger configuration space.
+Performance tuning is most useful when you treat it as a measurement process, not a fixed checklist. You can tune by changing one parameter at a time, or by running a designed experiment. You can compare profiles, or use automation and AI-assisted tools to explore a larger configuration space.
 
-There isn't a universal set of tuning parameters that works best for every application. The right settings depend on the request profile, response size, TLS configuration, cache behavior, upstream service behavior, network path, software version, system architecture, operating system, and other application-specific factors.
+There isn't a universal set of tuning parameters that works best for every application. The right settings depend on factors such as the request profile, response size, TLS configuration, and cache behavior. Upstream service behavior, network path, software version, system architecture, operating system, and other application-specific factors can also affect performance.
 
 Whatever method you use, keep the measurements repeatable. Record the system configuration, workload, software versions, and tuning parameters so you can identify which changes improved performance and which changes had little effect.
 
 ## Why tune NGINX
 
-NGINX performance can be limited by connection handling, kernel network settings, TLS processing, file I/O, upstream connection reuse, cache behavior, logging, or regular expression processing. Tuning helps you use the available compute, memory, storage, and network resources more efficiently.
+NGINX performance can be limited by connection handling, kernel network settings, TLS processing, file I/O, upstream connection reuse, cache behavior, logging, or regular expression processing. By tuning, you can use the available compute, memory, storage, and network resources more efficiently.
 
 Improved performance can give you higher throughput, lower latency, or better cost efficiency. A tuned configuration can increase capacity on the same system, or help you meet the same performance target with fewer compute resources.
 
@@ -26,3 +26,9 @@ The following example shows `wrk` throughput before and after tuning for an NGIN
 ![Bar chart comparing normalized NGINX API gateway wrk throughput before and after tuning. The out-of-box configuration is normalized to 1.00, and the tuned configuration reaches 1.13, showing about 13% higher RPS after tuning.#center](nginxoobvstuned.png "NGINX API gateway throughput before and after tuning")
 
 This result is an example, not a guaranteed improvement for every workload. Your results depend on the NGINX version, request rate, response size, TLS settings, client concurrency, upstream services, network configuration, and system resources.
+
+## What you've learned and what's next
+
+You've now learned why tuning NGINX is useful and reviewed an example benchmark demonstrating improvement in `wrk` throughput after tuning. 
+
+Next, you'll learn about Linux network settings, compiler options, and supporting libraries that can affect NGINX performance.

content/learning-paths/servers-and-cloud-computing/nginx_tune/kernel_comp_lib.md

@@ -1,10 +1,11 @@
 ---
-title: "Kernel, compiler, and libraries"
+title: Tune kernel, compiler, and library settings for performance
+description: Tune Linux network settings and evaluate compiler, OpenSSL, PCRE, and zlib choices that can affect NGINX performance on Arm-based platforms.
 weight: 3
 layout: "learningpathall"
 ---
 
-## Kernel configuration
+## Optimize kernel network stack settings
 
 NGINX tuning doesn't stop at `nginx.conf`. Foundational settings such as kernel network queues, socket buffers, compiler choices, and TLS libraries can affect throughput and latency. Treat these settings as part of the same measurement process you use for NGINX directives.
 
@@ -34,55 +35,58 @@ sudo sysctl -w net.ipv4.tcp_wmem="4096 8388608 8388608"
 
 These values are intentionally large. Size them for your expected connection rate, request pattern, and available memory.
 
-* `net.core.somaxconn`:
-  * This setting selects the maximum number of queued connections the kernel allows.
-  * If the NGINX server needs to support a large number of clients, it can be helpful to increase this parameter.
-  * A value of 65535 is likely excessive for many deployments. In practice, this value needs to be large enough to support the peak number of queued connections.
-* `net.core.rmem_max`:
-  * This setting selects the maximum read socket buffer size.
-  * `8 MiB` is likely more than enough for most use cases.
-  * Use a tool such as `ss` to check socket buffer utilization and select a value for this parameter.
-* `net.core.wmem_max`:
-  * This setting selects the maximum write socket buffer size.
-  * `8 MiB` is likely more than enough for most use cases.
-  * Use a tool such as `ss` to check socket buffer utilization and select a value for this parameter.
-* `net.ipv4.tcp_max_syn_backlog`:
-  * This setting selects the maximum number of connection requests that are pending but not established yet.
-  * A value of 65535 is likely excessive for many deployments. In practice, this value needs to be large enough to support the peak number of pending connection requests.
-* `net.ipv4.ip_local_port_range`:
-  * This setting selects the range of local ports the kernel can use.
-  * The example expands the port range. The default range is sufficient for many deployments.
-* `net.ipv4.tcp_rmem`:
-  * This setting selects the TCP read socket buffer size.
-  * `8 MiB` is likely more than enough for most use cases.
-  * Use a tool such as `ss` to check TCP buffer utilization and select a value for this parameter.
-* `net.ipv4.tcp_wmem`:
-  * This setting selects the TCP write socket buffer size.
-  * `8 MiB` is likely more than enough for most use cases.
-  * Use a tool such as `ss` to check TCP buffer utilization and select a value for this parameter.
+- `net.core.somaxconn`: Selects the maximum number of queued connections the kernel allows. If the NGINX server needs to support a large number of clients, it can be helpful to increase this parameter.
+
+  A value of 65535 is likely excessive for many deployments. In practice, this value needs to be large enough to support the peak number of queued connections.
+- `net.core.rmem_max`:  Selects the maximum read socket buffer size. `8 MiB` is likely more than enough for most use cases.
+
+  Use a tool such as `ss` to check socket buffer utilization and set a value for this parameter.
+- `net.core.wmem_max`: Selects the maximum write socket buffer size. `8 MiB` is likely more than enough for most use cases.
+  
+  Use a tool such as `ss` to check socket buffer utilization and set a value for this parameter.
+- `net.ipv4.tcp_max_syn_backlog`: Selects the maximum number of connection requests that are pending but not established yet.
+  
+  A value of 65535 is likely excessive for many deployments. In practice, this value needs to be large enough to support the peak number of pending connection requests.
+- `net.ipv4.ip_local_port_range`: Selects the range of local ports the kernel can use. The example expands the port range. The default range is sufficient for many deployments.
+- `net.ipv4.tcp_rmem`: Selects the TCP read socket buffer size. `8 MiB` is likely more than enough for most use cases.
+  
+  Use a tool such as `ss` to check TCP buffer utilization and set a value for this parameter.
+- `net.ipv4.tcp_wmem`: Selects the TCP write socket buffer size. `8 MiB` is likely more than enough for most use cases.
+  
+  Use a tool such as `ss` to check TCP buffer utilization and set a value for this parameter.
 
 ## Compiler considerations
 
-If you build NGINX from source, the compiler version and optimization flags can affect performance. Use a recent version of GCC, and consider flags such as `-mcpu` and `-flto` for additional optimization. These flags are explained in the [Migrating C/C++ applications](/learning-paths/servers-and-cloud-computing/migration/c/) section of the [Migrating applications to Arm servers](/learning-paths/servers-and-cloud-computing/migration/) Learning Path.
+If you build NGINX from source, the compiler version and optimization flags can affect performance. Use a recent version of GCC, and consider flags such as `-mcpu` and `-flto` for additional optimization. For more information about these flags, see the [Migrating C/C++ applications](/learning-paths/servers-and-cloud-computing/migration/c/) section of the [Migrating applications to Arm servers](/learning-paths/servers-and-cloud-computing/migration/) Learning Path.
 
 When you configure an NGINX source build, pass compiler flags with the `--with-cc-opt` option.
 
-To understand how to configure an NGINX build, review the [build NGINX from source](/learning-paths/servers-and-cloud-computing/nginx/build_from_source/) section of the [Learn how to deploy NGINX](/learning-paths/servers-and-cloud-computing/nginx/) Learning Path.
+To understand how to configure an NGINX build, see the [build NGINX from source](/learning-paths/servers-and-cloud-computing/nginx/build_from_source/) section of the [Learn how to deploy NGINX](/learning-paths/servers-and-cloud-computing/nginx/) Learning Path.
 
 ## OpenSSL
 
 NGINX relies on [OpenSSL](https://www.openssl.org/) for cryptographic operations. The OpenSSL version, GCC version, and compiler switches used to build OpenSSL can affect TLS performance. The Linux distribution default version of OpenSSL is sufficient for many deployments.
 
 Newer versions of OpenSSL might improve performance for some TLS workloads. To use a specific OpenSSL source tree, pass the `--with-openssl` switch when configuring the NGINX build. Point this switch to the directory that contains the source code of the OpenSSL version you want NGINX to link to. You can also use `--with-openssl-opt` to pass options to the OpenSSL build.
 
-NGINX can also be built with OpenSSL-compatible alternatives for some use cases. For example, the NGINX [QUIC and HTTP/3 documentation](https://nginx.org/en/docs/quic.html) shows how to configure NGINX with BoringSSL, LibreSSL, or QuicTLS. Consider this when you have a specific TLS or QUIC reason to evaluate another library, and measure the result with your workload.
+You can also build NGINX with OpenSSL-compatible alternatives for some use cases. For example, the NGINX [QUIC and HTTP/3 documentation](https://nginx.org/en/docs/quic.html) shows how to configure NGINX with BoringSSL, LibreSSL, or QuicTLS. Consider this when you have a specific TLS or QUIC reason to evaluate another library, and measure the result with your workload.
 
 Run `nginx -V` to check the TLS library information and configure options used by your NGINX build.
 
 ## Perl Compatible Regular Expressions (PCRE)
 
-NGINX relies on [PCRE](https://www.pcre.org/) for regular expression processing. One scenario where regular expressions are used is an API gateway path rewrite. The Linux distribution default version of PCRE is sufficient for many deployments. A newer version of PCRE might improve performance for regular expression-heavy configurations. The NGINX [installation instructions](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/#compiling-and-installing-from-source) explain how to build PCRE with NGINX from source.
+NGINX relies on [PCRE](https://www.pcre.org/) for regular expression processing. One scenario where regular expressions are used is an API gateway path rewrite. The Linux distribution default version of PCRE is sufficient for many deployments. A newer version of PCRE might improve performance for regular expression-heavy configurations. 
+
+To learn how to build PCRE with NGINX from source, see the NGINX [installation instructions](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/#compiling-and-installing-from-source).
 
 ## zlib for HTTP response compression
 
-NGINX relies on [zlib](https://zlib.net/) for HTTP response compression when the `ngx_http_gzip_module` directives are used. The Linux distribution default version of zlib is sufficient for many deployments. A newer version of zlib might improve performance for compression-heavy workloads. The NGINX [installation instructions](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/#compiling-and-installing-from-source) explain how to build zlib with NGINX from source.
+NGINX relies on [zlib](https://zlib.net/) for HTTP response compression when the `ngx_http_gzip_module` directives are used. The Linux distribution default version of zlib is sufficient for many deployments. A newer version of zlib might improve performance for compression-heavy workloads.
+
+ To learn how to build zlib with NGINX from source, see the NGINX [installation instructions](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/#compiling-and-installing-from-source).
+
+## What you've learned and what's next
+
+You've now learned how Linux network settings, compiler options, and supporting libraries can affect NGINX throughput and latency.
+
+Next, you'll review the configuration for a static file server and learn about optimizations that you can make.