Worker Process #

Memahami model proses Nginx adalah fondasi untuk semua tuning performa. Berbeda dari server tradisional yang membuat satu thread atau proses per koneksi, Nginx menggunakan model event-driven yang memungkinkan satu worker process menangani ribuan koneksi simultan.

Arsitektur Master-Worker #

nginx (master process)
├── worker process 1   ← menangani request
├── worker process 2   ← menangani request
├── worker process 3   ← menangani request
└── worker process 4   ← menangani request

Master process berjalan sebagai root. Tugasnya: membaca konfigurasi, membind socket, mengelola worker process (spawn, reload, kill). Master tidak menangani request sama sekali.

Worker process menangani semua koneksi dan request aktual. Setiap worker berjalan dalam satu thread tunggal tapi bisa menangani ribuan koneksi sekaligus menggunakan event loop (epoll di Linux, kqueue di BSD).

Satu worker process (event-driven):

koneksi 1 → terima request → tunggu backend → terima response → kirim ke klien
koneksi 2 → terima request ↗ (sementara tunggu, proses koneksi 1 di-yield)
koneksi 3 → terima request ↗
...
(semua diproses dalam satu thread, tanpa blocking, tanpa context switch)

Karena tidak ada blocking I/O dan tidak ada context switch antar thread, overhead per koneksi sangat kecil — di sinilah kecepatan Nginx berasal.

worker_processes: Berapa Banyak Worker #

# main context (di luar http block)

# Sesuaikan otomatis dengan jumlah CPU core
worker_processes auto;

# Atau tentukan manual
worker_processes 4;

auto adalah pilihan yang tepat untuk hampir semua kasus — Nginx membuat satu worker per CPU core. Ini memaksimalkan paralelisme tanpa overhead context switch yang tidak perlu.

Kapan mungkin perlu lebih dari jumlah CPU core? Jarang, tapi jika workload sangat I/O bound (banyak menunggu disk atau network), kadang menambah worker sedikit lebih banyak dari jumlah core bisa membantu.

# Cek jumlah CPU core di server
nproc
# atau
grep -c processor /proc/cpuinfo

worker_connections: Koneksi per Worker #

events {
    # Jumlah maksimum koneksi simultan per worker process
    worker_connections 1024;
}

Total koneksi maksimum server = worker_processes × worker_connections.

Untuk server dengan 4 worker dan worker_connections 1024:

Maksimum 4096 koneksi simultan

Tapi ingat: sebagai reverse proxy, satu request dari klien membuka dua koneksi — satu ke klien, satu ke backend. Jadi kapasitas efektif untuk request adalah setengahnya: ~2048 request simultan.

Nilai worker_connections juga dibatasi oleh file descriptor limit sistem:

# Cek file descriptor limit untuk user nginx
ulimit -n
# atau cek /etc/security/limits.conf

# Naikkan file descriptor limit untuk worker process
worker_rlimit_nofile 65535;

events {
    worker_connections 10240;   # Bisa lebih tinggi setelah naikkan rlimit
}

use: Pilih Event Model #

events {
    # Di Linux, epoll adalah yang terbaik — biasanya auto-dipilih
    use epoll;

    # Izinkan worker menerima banyak koneksi sekaligus (bukan satu per satu)
    # Direkomendasikan untuk workload dengan banyak koneksi baru per detik
    multi_accept on;
}

Nginx biasanya memilih event model terbaik secara otomatis. epoll di Linux dan kqueue di BSD/macOS adalah yang paling efisien. Kamu jarang perlu mengaturnya manual, tapi multi_accept on kadang membantu di server dengan traffic burst tinggi.

CPU Affinity: Ikat Worker ke Core Tertentu #

Untuk mengurangi cache miss CPU dan context switch antar core, kamu bisa mengikat setiap worker ke core CPU tertentu:

# Server dengan 4 core:
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
# Worker 1 → core 0 (0001)
# Worker 2 → core 1 (0010)
# Worker 3 → core 2 (0100)
# Worker 4 → core 3 (1000)

# Atau gunakan auto untuk affinity otomatis
worker_cpu_affinity auto;

Manfaat affinity biasanya kecil kecuali untuk workload yang sangat CPU-intensive atau server dengan NUMA architecture. Dalam kebanyakan kasus, worker_processes auto tanpa affinity manual sudah optimal.

Prioritas Proses #

# Naikkan prioritas schedulling worker process
# -20 = prioritas tertinggi, 19 = terendah, 0 = default
worker_priority -5;

Menurunkan nice value worker Nginx memberinya prioritas CPU lebih tinggi dari proses lain. Berguna di server yang menjalankan banyak proses bersamaan — Nginx mendapat CPU lebih cepat saat dibutuhkan.

Konfigurasi Lengkap yang Direkomendasikan #

# /etc/nginx/nginx.conf

user www-data;
worker_processes auto;
worker_rlimit_nofile 65535;

error_log /var/log/nginx/error.log warn;
pid /run/nginx.pid;

events {
    worker_connections 10240;
    use epoll;
    multi_accept on;
}

http {
    # ... konfigurasi lainnya
}

Menghitung Kebutuhan Server #

Sebagai panduan kasar untuk capacity planning:

Server: 4 core, worker_processes=4, worker_connections=10240

Kapasitas koneksi total:
  4 × 10240 = 40960 koneksi simultan

Sebagai reverse proxy (2 koneksi per request):
  40960 / 2 = ~20000 request simultan

Untuk 20000 request/detik dengan rata-rata response time 50ms:
  Koneksi aktif rata-rata = 20000 × 0.05 = 1000 koneksi
  (jauh di bawah kapasitas)

Bottleneck biasanya bukan Nginx, melainkan backend atau database.

Ringkasan #

worker_processes auto adalah pilihan terbaik untuk hampir semua kasus — satu worker per CPU core.
worker_connections × worker_processes = total koneksi maksimum; untuk reverse proxy bagi dua untuk mendapat kapasitas request efektif.
Naikkan worker_rlimit_nofile sebelum menaikkan worker_connections — file descriptor limit sistem bisa menjadi bottleneck.
multi_accept on membantu performa saat ada banyak koneksi baru yang masuk bersamaan (traffic burst).
Bottleneck performa biasanya ada di backend atau database, bukan di Nginx itu sendiri.

← Sebelumnya: Rotasi Log Berikutnya: Kompresi Gzip →