Tune NGINX performance on Arm-based platforms
Introduction
Measure the impact of NGINX tuning
Tune kernel, compiler, and library settings for performance
Tune an NGINX static file server for performance
Tune an NGINX reverse proxy or API gateway for performance
Load test your NGINX optimizations
Next Steps
Tune NGINX performance on Arm-based platforms
Who is this for?
This Learning Path is for software developers and system administrators who want to optimize NGINX performance on Arm-based platforms.
What will you learn?
Upon completion of this Learning Path, you will be able to:
- Configure Linux network settings that affect NGINX connection handling.
- Tune NGINX directives for static file server, reverse proxy, and API gateway workloads.
- Evaluate compiler, OpenSSL, PCRE, and zlib choices that can affect NGINX performance.
- Measure NGINX performance before and after tuning.
Prerequisites
Before starting, you will need the following:
- 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 don’t already have an NGINX setup, see Learn how to deploy NGINX .
Summary
This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
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.Frequently asked questions
These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.
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.
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.
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.
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.
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.