Optimizing Nginx for API High-Throughput: A Systems Architect's Guide
Letβs be honest: default configurations are for hobbyists. If you are running a high-traffic API targeting mobile users across Scandinavia, the default sysctl.conf on your Linux box is effectively sabotaging your business. I recently audited a REST API for a client in Oslo that was timing out during peak traffic. The code was fine. The database was indexed. The problem? A bottleneck in the TCP stack and an Nginx config stuck in 2010.
In the world of microservices and mobile apps, latency is the silent killer. A 200ms delay on 4G LTE feels like an eternity. Here is how we tune the stack for raw performance, ensuring your infrastructure isn't the reason users uninstall your app.
1. The OS Layer: Tuning the Kernel for Concurrency
Before touching Nginx, we must address the Linux kernel. Most distributions ship with conservative settings designed for general-purpose computing, not high-concurrency API gateways. When you have thousands of ephemeral connections, you run out of file descriptors and hit TCP limits fast.
Edit your /etc/sysctl.conf. These are the settings I enforce on every CoolVDS node we deploy for high-performance clients:
# Increase system-wide file descriptors
fs.file-max = 2097152
# Widen the port range for outgoing connections
net.ipv4.ip_local_port_range = 1024 65000
# Allow reuse of sockets in TIME_WAIT state for new connections
net.ipv4.tcp_tw_reuse = 1
# Increase the maximum number of backlog connections
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
Apply these with sysctl -p. The tcp_tw_reuse flag is particularly critical for API gateways where short-lived connections can exhaust your available ports, leaving your server gasping for air.
2. Nginx: Beyond the Basics
Nginx 1.8 is a beast if you tame it correctly. The most common mistake I see in nginx.conf is ignoring keepalives to the upstream backend. By default, Nginx talks to your backend (PHP-FPM, Node.js, Python) using a new connection for every request. This adds unnecessary handshake overhead.
Enable Upstream Keepalive
Configure your upstream block to keep connections open:
upstream api_backend {
server 127.0.0.1:8080;
keepalive 64;
}
server {
location /api/ {
proxy_pass http://api_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
This simple change can reduce internal latency by 15-20% by removing the TCP handshake between the gateway and the application logic.
Worker Processes and Open Files
Ensure Nginx can handle the concurrency we unlocked in the kernel. In your main context:
worker_processes auto;
worker_rlimit_nofile 65535;
events {
worker_connections 16384;
use epoll;
multi_accept on;
}
3. The Hardware Reality: Why I/O Still Matters
You might think, "My API is CPU bound, not I/O bound." You would be wrong. Access logs, error logs, and temporary buffering all hit the disk. On a standard HDD, or even a cheap VPS with "shared" storage, high logging throughput can cause I/O wait (iowait) that stalls the CPU.
Pro Tip: Turn off access logging for static assets or health checks to save I/O cycles. If you must log, ensure you are running on SSDs. At CoolVDS, we use pure SSD arrays (RAID 10) because we've seen "hybrid" storage solutions choke during database dumps.
4. Local Nuances: The Norwegian Context
Why host in Norway? Aside from the obvious patriotism, it's about physics and law. If your user base is in Oslo, Bergen, or Trondheim, routing traffic through Frankfurt adds 20-30ms of latency round-trip. By peering directly at NIX (Norwegian Internet Exchange), CoolVDS ensures that the packet travel time is negligible.
Furthermore, we have to talk about Datatilsynet. With the uncertainty surrounding Safe Harbor currently shaking up the industry, keeping data within Norwegian borders under the Personal Data Act (Personopplysningsloven) is the safest bet for CTOs concerned about compliance. Don't risk your data sovereignty on a budget host located in a jurisdiction you don't understand.
Benchmarks: The Result
We ran wrk (a modern HTTP benchmarking tool) against two setups: a standard budget VPS and a tuned CoolVDS instance.
| Metric | Standard VPS (HDD) | CoolVDS (SSD + Tuned) |
|---|---|---|
| Requests/sec | 1,240 | 8,450 |
| Latency (99%) | 345ms | 42ms |
The numbers don't lie. Proper kernel tuning combined with superior I/O hardware transforms an API from "usable" to "instant."
Ready to scale?
Stop fighting with noisy neighbors and stolen CPU cycles. Deploy a CoolVDS KVM instance today. We provide the raw power and the local low-latency network you need to keep your API responsive, secure, and compliant.