NGINX: worker_processes auto; — Tidak Selalu Optimal

Di banyak tutorial, sering terlihat:

worker_processes auto;

Kalau diterjemahkan:

Nginx akan otomatis menyesuaikan jumlah worker dengan jumlah core CPU.

Kedengarannya praktis & aman. Tapi realitanya, tidak selalu optimal, apalagi di production dengan trafik nyata.

---

1. Apa Itu worker_processes?

worker_processes menentukan jumlah worker process Nginx:

• Setiap worker = event loop non-blocking
• Menangani request
• Bisa multi-threaded dengan worker_connections tinggi

Secara sederhana:

worker × connections = kapasitas maksimum

---

2. auto Artinya Apa?

• Nginx membaca /proc/cpuinfo
• Mengambil jumlah core CPU fisik/logical
• Set jumlah worker = jumlah core

Kelebihan:

• Konfigurasi cepat
• Tidak perlu hitung manual

---

3. Mengapa Tidak Selalu Optimal?

1️⃣ Worker Lebih Banyak ≠ Lebih Cepat

• Jika backend lambat → worker tetap menunggu I/O
• Worker idle tapi tetap memakan memori

2️⃣ Overhead Context Switch

• Terlalu banyak worker → CPU bolak-balik context switch
• CPU usage naik, latency meningkat

3️⃣ Worker Sedikit Bisa Lebih Baik

• Dengan worker_connections tinggi, 1 worker bisa menangani ribuan koneksi
• Tergantung trafik & nature request

---

4. Faktor yang Mempengaruhi Optimal Worker

1. Jenis trafik
   • Static file → worker lebih banyak sedikit membantu
   • Backend dynamic → terlalu banyak worker tidak berarti
2. Jumlah connection per worker (worker_connections)
   • Standar: 1024–4096
   • Bisa scaling sesuai traffic
3. Hardware & OS
   • Kernel scheduling
   • IRQ affinity
4. I/O vs CPU bound
   • File static → I/O bound → worker lebih banyak kadang membantu
   • PHP-FPM / upstream → CPU bound → worker lebih sedikit, connection tinggi lebih efisien

---

5. Cara Hitung Worker yang Lebih Realistis

Rumus kasar:

worker_processes ≈ min(num_cores, estimated_concurrent_connections / worker_connections)

Contoh:

• 8 core
• 10.000 concurrent request
• 4.096 worker_connections

Hitung:

needed_worker = ceil(10000 / 4096) ≈ 3

• Bisa set worker_processes 3; meski CPU punya 8 core
• Lebih sedikit context switch, tetap bisa menangani semua koneksi

---

6. Monitor Worker di Production

Tools yang berguna:

• htop → lihat CPU usage worker
• nginx_status (stub_status module) → active connections
• netstat / ss → connection backlog
• Log slow requests → pastikan worker tidak overload

---

7. Kesalahan Fatal dengan auto

1. Anggap auto = always perfect ❌
   • Bisa overload CPU, memory, context switch tinggi
2. Tidak menyesuaikan worker_connections ❌
   • Worker sedikit + connections rendah = bottleneck
3. Tidak memantau actual usage ❌
   • Worker idle atau terlalu banyak → sia-sia

---

8. Tips Praktis

• Mulai dengan auto → lihat traffic
• Monitor active connections & CPU → tweak manual jika perlu
• Jangan lupa sesuaikan worker_rlimit_nofile
• Gunakan ulimit -n untuk membuka file descriptors cukup tinggi

---

9. Studi Kasus

• Server 8 core, trafik tinggi, backend lambat
• worker_processes auto → CPU usage tinggi, latency naik
• Setting manual worker_processes 4 + worker_connections 8192 → latency turun, throughput stabil

---

10. Kesimpulan

worker_processes auto; praktis tapi bukan jaminan optimal.

Kalimat inti:

Worker yang ideal tergantung traffic, backend, dan hardware, bukan sekadar jumlah core.