Nginx vs Apache #

Ketika kamu memilih web server, dua nama ini selalu muncul: Nginx dan Apache. Pertanyaan “mana yang lebih baik?” tidak memiliki jawaban tunggal — karena keduanya memiliki kekuatan di skenario yang berbeda. Yang lebih berguna adalah memahami mengapa keduanya berbeda secara fundamental, lalu memilih berdasarkan kebutuhan spesifik proyekmu. Artikel ini membangun pemahaman itu dengan perbandingan yang jujur.

Perbedaan Arsitektur: Akar dari Segalanya #

Hampir semua perbedaan performa dan perilaku antara Nginx dan Apache bisa ditelusuri ke satu keputusan desain mendasar: bagaimana mereka menangani koneksi bersamaan.

Apache: Process-Based (dan Thread-Based) #

Apache menggunakan Multi-Processing Module (MPM) untuk mengelola koneksi. Ada beberapa MPM yang bisa dipilih:

Apache MPM Prefork (model paling tradisional):

Request 1 ──▶ [Process 1] ──▶ Proses request ──▶ Kirim respons
                               (blocking — proses ini tidak
                               bisa tangani request lain)

Request 2 ──▶ [Process 2] ──▶ Proses request ──▶ Kirim respons
Request 3 ──▶ [Process 3] ──▶ ...
...
Request N ──▶ [Process N] ──▶ ...

Setiap koneksi = 1 proses terpisah
Konsumsi RAM per proses: 8-25 MB

Apache juga punya MPM Worker (menggunakan thread, lebih efisien dari prefork) dan MPM Event (lebih modern, mendekati model Nginx). Namun, bahkan dengan MPM Event, Apache tetap memiliki overhead yang lebih tinggi daripada Nginx untuk skenario koneksi tinggi.

Nginx: Event-Driven Asinkron #

Nginx menggunakan pendekatan yang fundamentally berbeda:

Nginx Event-Driven Model:

Master Process
    │
    ├── Worker Process 1 (mengelola ribuan koneksi)
    │       │
    │       ├── Koneksi 1 (sedang menunggu data dari disk)
    │       ├── Koneksi 2 (sedang mengirim respons)
    │       ├── Koneksi 3 (baru terhubung)
    │       ├── Koneksi 4 (menunggu backend)
    │       └── ... (ratusan/ribuan koneksi lainnya)
    │
    ├── Worker Process 2 (sama seperti di atas)
    └── Worker Process 3 (sama seperti di atas)

Jumlah worker biasanya = jumlah CPU core
Setiap worker bisa tangani ribuan koneksi secara non-blocking

Kunci dari model ini adalah non-blocking I/O dan event loop. Ketika Nginx menunggu respons dari disk atau dari backend, ia tidak memblok proses tersebut — ia mendaftarkan event “kabari aku kalau sudah selesai” dan melanjutkan menangani koneksi lain. Ketika datanya siap, event loop menanganinya.

Perbandingan Konsumsi Memori (estimasi):

Skenario: 1000 koneksi bersamaan

Apache (prefork):
  1000 proses × 8 MB = 8.000 MB = 8 GB RAM

Apache (worker MPM):
  100 proses × 10 thread × 1 MB/thread = ~1 GB RAM

Nginx:
  4 worker processes × (ribuan koneksi per worker)
  ~2-3 MB per worker process = ~12 MB RAM (total)

Nginx menggunakan ~650x lebih sedikit RAM untuk skenario ini.

Perbandingan Performa: Benchmark dan Realita #

Benchmark web server sering diperdebatkan karena hasilnya sangat bergantung pada kondisi pengujian. Tapi beberapa pola konsisten muncul di berbagai pengujian selama bertahun-tahun:

Melayani File Statis #

Performa File Statis (relatif):

Nginx:  ████████████████████  100% (baseline)
Apache: ████████████          ~60-70%

Keunggulan Nginx untuk file statis:
  ✓ sendfile() system call (zero-copy)
  ✓ Model event-driven tidak ada overhead process/thread
  ✓ Konsumsi CPU lebih rendah per request

Untuk melayani file HTML, CSS, JS, gambar — Nginx secara konsisten lebih cepat dan lebih efisien daripada Apache. Ini adalah use case yang paling umum dan paling sering di-benchmark.

Koneksi Bersamaan Tinggi #

Throughput di Bawah Beban Tinggi (estimasi relatif):

10 koneksi bersamaan:
  Nginx:  ██████████  Setara dengan Apache
  Apache: ██████████

1000 koneksi bersamaan:
  Nginx:  ████████████████████  Stabil, throughput tinggi
  Apache: ████████              Mulai tertekan

10.000 koneksi bersamaan:
  Nginx:  ████████████████████  Tetap stabil
  Apache: ██                    Sangat lambat / crash

Kesimpulan: Keunggulan Nginx makin terasa dengan semakin
banyak koneksi bersamaan.

Konten Dinamis (PHP, Python, dll.) #

Ini area yang lebih seimbang. Untuk konten dinamis, kedua server harus berkomunikasi dengan backend eksternal (PHP-FPM, Python WSGI, dll.). Bottleneck biasanya ada di backend, bukan di web server itu sendiri.

Untuk konten dinamis:
  - Apache dengan mod_php: PHP berjalan dalam proses Apache
    (lebih mudah setup, tapi lebih boros memori)
  - Apache dengan PHP-FPM: mirip dengan Nginx
  - Nginx dengan PHP-FPM: performanya sebanding

Dalam skenario ini, perbedaan performa antara Nginx dan Apache
lebih kecil karena bottleneck ada di eksekusi PHP/Python,
bukan di web server.

Konfigurasi: Pendekatan yang Berbeda #

Salah satu perbedaan yang paling terasa dalam penggunaan sehari-hari adalah cara keduanya dikonfigurasi.

Apache: .htaccess dan Per-Directory Config #

Apache mendukung file konfigurasi .htaccess yang bisa ditempatkan di direktori manapun. Ini memungkinkan konfigurasi per-direktori tanpa perlu akses ke file konfigurasi utama server.

# File: /var/www/html/app/.htaccess
# (Apache membaca ini setiap ada request ke direktori ini)

RewriteEngine On
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# Password protect direktori tertentu
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Kelebihan .htaccess: pengguna shared hosting bisa mengkonfigurasi web server untuk direktori mereka tanpa akses root.

Kekurangan .htaccess: setiap request, Apache harus memeriksa .htaccess di setiap direktori dari root hingga direktori yang diminta. Ini bisa berpengaruh signifikan pada performa, terutama di server dengan banyak file.

Overhead .htaccess pada setiap request:

GET /blog/2024/january/post.html

Apache harus baca:
  /var/www/html/.htaccess
  /var/www/html/blog/.htaccess
  /var/www/html/blog/2024/.htaccess
  /var/www/html/blog/2024/january/.htaccess

= 4 disk read tambahan per request
  (bisa 0 jika tidak ada, tapi Apache tetap harus cek)

Nginx: Konfigurasi Terpusat #

Nginx tidak mendukung .htaccess. Semua konfigurasi harus ada di file konfigurasi utama (atau file yang di-include dari sana). Ini adalah keputusan desain yang disengaja.

# /etc/nginx/sites-available/myapp.conf
server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    # Ini yang setara dengan .htaccess untuk URL rewriting
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        include fastcgi_params;
    }
}

Kelebihan konfigurasi terpusat: lebih mudah di-review, di-audit, dan tidak ada overhead per-request untuk membaca file konfigurasi dari disk.

Kekurangan: tidak cocok untuk shared hosting di mana pengguna perlu mengkonfigurasi server untuk direktori mereka sendiri.

Perbandingan Pendekatan Konfigurasi:

                    Apache          Nginx
──────────────────────────────────────────
.htaccess           ✓ Didukung      ✗ Tidak ada
Per-dir config      ✓ Mudah         ✗ Tidak ada
Konfigurasi global  ✓               ✓
Reload tanpa restart ✓              ✓
Overhead per request Lebih tinggi   Lebih rendah
Audit security      Lebih sulit     Lebih mudah

Modul: Cara Ekstensi yang Berbeda #

Cara keduanya di-extend juga mencerminkan filosofi yang berbeda.

Apache: Modul Dinamis yang Mudah #

Apache memiliki sistem modul yang sangat fleksibel. Kamu bisa mengaktifkan dan menonaktifkan modul tanpa kompilasi ulang:

# Apache: aktifkan/nonaktifkan modul sangat mudah
sudo a2enmod rewrite   # aktifkan mod_rewrite
sudo a2enmod ssl       # aktifkan mod_ssl
sudo a2enmod headers   # aktifkan mod_headers
sudo a2dismod status   # nonaktifkan mod_status
sudo systemctl reload apache2

# Modul berjalan dalam proses Apache itu sendiri
# (in-process modules — lebih mudah tapi kurang isolasi)

Ekosistem modul Apache sangat besar. Ada modul untuk hampir semua kebutuhan: mod_security untuk WAF, mod_pagespeed untuk optimasi, mod_auth_* untuk berbagai metode autentikasi.

Nginx: Modul Statis (dengan Pengecualian) #

Secara tradisional, Nginx membutuhkan kompilasi ulang untuk menambah modul. Ini berubah dengan diperkenalkannya dynamic modules di Nginx 1.9.11 (2016):

# Nginx: lihat modul yang sudah dikompilasi
nginx -V 2>&1 | tr -- - '\n' | grep module

# Nginx Plus dan beberapa distro mendukung dynamic modules
# yang bisa di-load tanpa kompilasi ulang:
# /etc/nginx/nginx.conf
load_module modules/ngx_http_geoip_module.so;
load_module modules/ngx_stream_module.so;

Meskipun dynamic modules sudah ada, ekosistem modul Nginx masih tidak selengkap Apache dalam hal kemudahan instalasi. Banyak fitur yang membutuhkan modul di Apache justru sudah built-in di Nginx (gzip, SSL, proxy, dll.).

Ekosistem Modul:

Apache:
  + Ekosistem lebih besar
  + Lebih mudah install modul
  + mod_php (PHP berjalan in-process)
  - Modul in-process bisa crash seluruh server
  - Lebih besar footprint memori

Nginx:
  + Modul inti sudah lengkap (proxy, SSL, gzip built-in)
  + Dynamic modules lebih isolasi
  - Ekosistem pihak ketiga lebih kecil
  - Beberapa fitur butuh kompilasi khusus

Penanganan Konten Dinamis: .htaccess vs Proxy #

Ini salah satu area di mana developer sering bingung tentang perbedaan pendekatan.

Apache + mod_php: PHP In-Process #

Apache dengan mod_php:

Browser ──▶ Apache Process ──▶ mod_php (dalam proses yang sama)
                               ──▶ Eksekusi PHP
                               ──▶ Respons HTML

Kelebihan: setup sederhana
Kekurangan: PHP crash = Apache crash, memori besar

Nginx + PHP-FPM: PHP Out-of-Process #

Nginx dengan PHP-FPM:

Browser ──▶ Nginx ──▶ FastCGI ──▶ PHP-FPM (proses terpisah)
                                   ──▶ Eksekusi PHP
                                   ──▶ Respons ke Nginx
                                   ──▶ Nginx kirim ke browser

Kelebihan: PHP crash tidak matikan Nginx, bisa scale terpisah
Kekurangan: setup lebih kompleks

Nginx mendorong model out-of-process untuk semua konten dinamis — PHP-FPM untuk PHP, Gunicorn/uWSGI untuk Python, Passenger untuk Ruby, dan sebagainya. Ini dianggap arsitektur yang lebih sehat karena memisahkan tanggung jawab.

Shared Hosting vs Dedicated Hosting #

Ini adalah faktor yang sering tidak dibahas tapi sangat relevan:

Shared Hosting (banyak pengguna di satu server):
  Apache lebih cocok karena:
  ✓ Setiap pengguna bisa punya .htaccess sendiri
  ✓ Tidak butuh akses root untuk konfigurasi dasar
  ✓ cPanel/Plesk secara historis didesain untuk Apache

Dedicated Server / VPS / Cloud:
  Nginx lebih cocok karena:
  ✓ Kamu kontrol penuh konfigurasi
  ✓ Performa lebih baik untuk trafik tinggi
  ✓ Konsumsi memori lebih rendah
  ✓ Cocok untuk arsitektur microservice dan container

Inilah mengapa Apache masih sangat dominan di shared hosting, sementara Nginx mendominasi di deployment cloud dan enterprise modern.

Decision Tree: Mana yang Harus Dipilih? #

Mulai dari sini:
       │
       ▼
Apakah kamu di shared hosting?
       │
   ┌───┴───┐
  Ya      Tidak
   │         │
   ▼         ▼
[Apache]  Apakah kamu butuh .htaccess
          (misal: deploy CMS yang
          menggunakan .htaccess)?
               │
           ┌───┴───┐
          Ya      Tidak
           │         │
           ▼         ▼
        [Apache]  Apakah trafik kamu
                  sangat tinggi (>1000
                  req/detik) atau memory
                  sangat terbatas?
                        │
                    ┌───┴───┐
                   Ya      Tidak
                    │         │
                    ▼         ▼
                 [Nginx]   Keduanya bisa,
                           Nginx umumnya
                           lebih disarankan
                           untuk deployment baru

Migrasi dari Apache ke Nginx #

Jika kamu sudah menggunakan Apache dan ingin beralih ke Nginx, ada beberapa hal yang perlu diperhatikan:

Translate .htaccess ke Nginx Config #

Ini adalah tantangan terbesar dalam migrasi. Setiap .htaccess harus diubah menjadi blok konfigurasi di file Nginx.

# Apache .htaccess — WordPress
Options -Indexes
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# Nginx equivalent — WordPress
location / {
    # Coba file → direktori → fallback ke index.php
    try_files $uri $uri/ /index.php?$args;
}

# Menonaktifkan directory listing (equivalent Options -Indexes)
autoindex off;

# Apache — redirect HTTP ke HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Nginx equivalent — redirect HTTP ke HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# Apache — password protect direktori
AuthType Basic
AuthName "Protected"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

# Nginx equivalent
location /admin {
    auth_basic "Protected";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

Checklist Migrasi Apache ke Nginx #

PERSIAPAN:
  □ Dokumentasikan semua .htaccess yang ada
  □ Catat semua custom module Apache yang digunakan
  □ Backup konfigurasi Apache saat ini
  □ Test di staging environment dulu

KONVERSI:
  □ Konversi semua RewriteRule ke try_files / rewrite Nginx
  □ Konversi auth (Basic Auth, Digest) ke Nginx equivalent
  □ Konversi custom error pages
  □ Konversi SSL configuration
  □ Konversi custom headers

TESTING:
  □ Test semua URL yang ada (gunakan crawler atau log analysis)
  □ Test redirect (pastikan tidak ada loop redirect)
  □ Test form submission dan file upload
  □ Test WebSocket jika ada
  □ Performance test (AB, wrk, atau k6)

DEPLOYMENT:
  □ Test konfigurasi Nginx: nginx -t
  □ Planned maintenance window untuk cutover
  □ Monitor error log setelah migration
  □ Siapkan rollback plan

Konfigurasi PHP: Apache mod_php vs Nginx PHP-FPM #

Ini adalah perbedaan paling signifikan dalam praktik sehari-hari untuk developer PHP:

Apache + mod_php (cara tradisional) #

# Apache: PHP berjalan di dalam proses Apache
# Tidak perlu konfigurasi tambahan setelah install

# /etc/apache2/sites-available/mysite.conf
<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html

    # mod_php langsung menangani .php
    # Tidak perlu proxy atau fastcgi

    <Directory /var/www/html>
        AllowOverride All   # Izinkan .htaccess
        Require all granted
    </Directory>
</VirtualHost>

Konfigurasi minimal, tapi semua PHP berjalan dalam proses Apache — artinya setiap request PHP membutuhkan memori Apache yang lengkap.

Nginx + PHP-FPM (cara modern) #

# Nginx: PHP dijalankan oleh PHP-FPM, terpisah dari Nginx

server {
    listen 80;
    server_name example.com;
    root /var/www/html;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # Teruskan file .php ke PHP-FPM
    location ~ \.php$ {
        # Pastikan file ada (keamanan)
        try_files $uri =404;

        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # Jangan izinkan akses langsung ke .htaccess (keamanan)
    location ~ /\.ht {
        deny all;
    }
}

Konfigurasi lebih verbose, tapi PHP-FPM berjalan terpisah dengan pool prosesnya sendiri yang bisa dikonfigurasi dan di-scale secara independen.

Perbandingan mod_php vs PHP-FPM:

                   mod_php         PHP-FPM
─────────────────────────────────────────────────
Setup complexity    Mudah           Lebih kompleks
Memori per request  Lebih besar     Lebih kecil
Crash isolation     ✗ PHP crash     ✓ PHP crash
                    = Apache crash  ≠ Nginx crash
Scaling PHP         Sulit (terkait  ✓ Bisa scale
                    jumlah proses   PHP-FPM pool
                    Apache)         terpisah
Multiple PHP ver    Sulit           ✓ Mudah
Performance         Cukup           Lebih baik

Logging dan Debugging: Perbedaan Pendekatan #

Cara kedua server mencatat log juga berbeda dan mempengaruhi workflow debugging.

Apache Logging #

# /etc/apache2/apache2.conf
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

# Per virtual host
<VirtualHost *:80>
    ErrorLog ${APACHE_LOG_DIR}/mysite-error.log
    CustomLog ${APACHE_LOG_DIR}/mysite-access.log combined
    LogLevel warn
</VirtualHost>

Nginx Logging #

# /etc/nginx/nginx.conf
http {
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log main;
    error_log /var/log/nginx/error.log warn;
}

# Per server block
server {
    access_log /var/log/nginx/mysite-access.log main;
    error_log /var/log/nginx/mysite-error.log warn;
}

Format log keduanya sangat mirip dan bisa dikustomisasi. Perbedaan utama: Nginx punya lebih banyak variabel bawaan yang bisa dimasukkan ke log (seperti $upstream_response_time, $upstream_addr) yang sangat berguna untuk debugging proxy.

Performa Real-World: Bukan Hanya Benchmark Sintetis #

Benchmark sintetis sering menunjukkan perbedaan besar antara Nginx dan Apache, tapi di dunia nyata situasinya lebih nuanced.

Kapan Perbedaan Terasa Signifikan #

Perbedaan performa TERASA JELAS ketika:

1. Trafik sangat tinggi (>1000 req/detik per server)
   → Nginx menangani dengan lebih stabil

2. Banyak koneksi bersamaan (>500 concurrent)
   → Nginx konsumsi memori jauh lebih rendah

3. Banyak file statis kecil
   → Nginx sendfile() lebih efisien

4. Server memori terbatas (512 MB atau kurang)
   → Nginx bisa berjalan dengan overhead sangat kecil

5. Long-polling atau SSE (Server-Sent Events)
   → Nginx menangani koneksi long-lived jauh lebih baik

Kapan Perbedaan Tidak Signifikan #

Perbedaan performa TIDAK TERASA ketika:

1. Trafik rendah (<100 req/detik)
   → Keduanya lebih dari cukup

2. Aplikasi berat dengan database query lambat
   → Bottleneck ada di database, bukan web server

3. Server dengan RAM besar (>8 GB) dan beban sedang
   → Apache punya cukup RAM, perbedaan tidak terasa

4. Upload/download file besar
   → I/O jaringan adalah bottleneck, bukan web server

Jika kamu menjalankan blog personal dengan 100 pengunjung per hari, pilihan antara Nginx dan Apache tidak akan membuat perbedaan yang terasa. Tapi jika kamu membangun platform dengan jutaan pengguna, keputusan ini sangat relevan.

Penggunaan Bersamaan: Nginx sebagai Front-End Apache #

Salah satu konfigurasi yang cukup umum (terutama untuk hosting lama yang sudah menggunakan Apache) adalah menggunakan keduanya:

Internet
    │
    ▼
[Nginx] (port 80/443)
  │
  ├── File statis: dilayani langsung oleh Nginx
  │   (HTML, CSS, JS, gambar)
  │
  └── Request dinamis: diteruskan ke Apache (port 8080)
      ├── Apache + mod_php
      └── Apache + .htaccess (tetap berfungsi!)

Konfigurasi ini memberikan performa Nginx untuk file statis, sambil mempertahankan kemampuan .htaccess dari Apache untuk konten dinamis. Ini sering digunakan sebagai langkah transisi sebelum migrasi penuh ke Nginx.

Kasus Nyata: Kapan Apache Masih Lebih Baik #

Meskipun Nginx sering dianggap “yang lebih modern”, ada skenario konkret di mana Apache tetap pilihan yang lebih praktis:

Shared Hosting yang Sudah Ada #

Jika kamu mengambil alih server shared hosting yang sudah berjalan dengan Apache, biaya migrasi ke Nginx (konversi semua .htaccess, training tim, testing menyeluruh) seringkali tidak sebanding dengan manfaatnya jika trafik masih rendah-sedang.

Aplikasi CMS Lama yang Bergantung .htaccess #

WordPress, Joomla, Drupal, dan banyak CMS PHP lainnya menggunakan .htaccess secara ekstensif untuk pretty URLs, security rules, dan konfigurasi per-plugin. Meskipun semua ini bisa dikonversi ke Nginx, prosesnya bisa rumit dan rawan error.

WordPress dengan Apache:
  - Install WordPress
  - Apache langsung baca .htaccess bawaan WordPress
  - Pretty URLs langsung bekerja
  - Selesai.

WordPress dengan Nginx:
  - Install WordPress
  - Buat konfigurasi Nginx yang equivalent dengan .htaccess WordPress
  - Test semua URL pattern
  - Test plugin yang mungkin menambah aturan .htaccess
  - Pastikan setiap plugin baru tidak mengandalkan .htaccess
  - Lebih banyak setup, tapi setelah selesai performa lebih baik

Tim yang Sudah Familiar dengan Apache #

Jika seluruh tim sudah bertahun-tahun bekerja dengan Apache, ada nilai nyata dalam konsistensi. Learning curve Nginx tidak besar, tapi context switching membutuhkan waktu. Untuk tim kecil dengan deadline ketat, ini bisa menjadi faktor yang relevan.

Tools untuk Benchmark Sendiri #

Daripada mengandalkan benchmark orang lain, kamu bisa menguji sendiri dengan tools yang tersedia:

Apache Bench (ab) #

# Install
sudo apt install apache2-utils

# Benchmark sederhana: 10.000 request, 100 concurrent
ab -n 10000 -c 100 http://your-server/

# Output yang relevan:
# Requests per second:    8452.34 [#/sec] (mean)
# Time per request:       11.831 [ms] (mean)
# Transfer rate:          6891.12 [Kbytes/sec] received

wrk (lebih modern) #

# Install
sudo apt install wrk

# Benchmark 30 detik, 12 threads, 400 koneksi bersamaan
wrk -t12 -c400 -d30s http://your-server/

# Output:
# Running 30s test @ http://your-server/
# 12 threads and 400 connections
# Thread Stats   Avg      Stdev     Max   +/- Stdev
#   Latency    12.34ms   3.21ms  89.12ms   91.23%
#   Req/Sec     2.71k   312.45    4.12k    78.34%
# 972034 requests in 30.10s, 789.23MB read
# Requests/sec:  32293.41

k6 (untuk skenario yang lebih kompleks) #

// test.js — benchmark k6
import http from 'k6/http';
import { sleep } from 'k6';

export let options = {
    stages: [
        { duration: '30s', target: 100 },   // ramp up ke 100 user
        { duration: '60s', target: 100 },   // steady 100 user
        { duration: '30s', target: 0 },     // ramp down
    ],
};

export default function () {
    http.get('http://your-server/');
    sleep(1);
}

# Jalankan k6
k6 run test.js

SSL Performance: Apache vs Nginx #

Untuk HTTPS, ada perbedaan kecil dalam cara keduanya menangani TLS:

TLS Handshake (koneksi pertama):
  Apache dan Nginx keduanya menggunakan OpenSSL/BoringSSL
  Perbedaan performa TLS handshake sangat kecil

TLS Session Resumption:
  Nginx memiliki implementasi TLS session cache yang efisien:

nginx.conf:
ssl_session_cache shared:SSL:10m;  # 10MB shared cache antar worker
ssl_session_timeout 1d;             # Session valid 1 hari
ssl_session_tickets off;            # Nonaktifkan tickets (lebih aman)

  Dengan session resumption, TLS handshake untuk klien yang kembali
  jauh lebih cepat — tidak perlu full handshake lagi.

Perbedaan performa TLS antara Nginx dan Apache modern tidak signifikan dalam praktik — keduanya menggunakan library yang sama. Faktor lebih penting adalah konfigurasi TLS yang tepat (cipher suite, protokol, dll.) yang akan dibahas di Section 07.

Kesimpulan: Konteks yang Menentukan #

Tidak ada jawaban universal untuk “Nginx atau Apache?”. Yang ada adalah konteks:

Pilih Nginx jika:
  ✓ Deployment baru di cloud/VPS/dedicated
  ✓ Trafik tinggi atau potensi trafik tinggi
  ✓ Kamu kontrol penuh konfigurasi server
  ✓ Arsitektur microservice / container
  ✓ Butuh performa file statis yang maksimal
  ✓ RAM terbatas
  ✓ WebSocket atau long-polling
  ✓ API gateway atau reverse proxy

Pilih Apache jika:
  ✓ Shared hosting (terutama dengan cPanel)
  ✓ CMS lama yang bergantung .htaccess
  ✓ Tim sudah sangat familiar dengan Apache
  ✓ Butuh modul khusus yang hanya tersedia di Apache
  ✓ Migrasi dari Apache butuh effort besar tapi manfaat kecil

Pertimbangkan keduanya jika:
  ✓ Nginx front-end (file statis + SSL) + Apache backend (PHP)
  ✓ Lingkungan transisional saat migrasi bertahap

Dalam praktik, mayoritas infrastruktur web baru yang dibangun hari ini menggunakan Nginx — bukan karena Apache buruk, tapi karena Nginx menawarkan titik manis yang lebih sesuai dengan cara infrastruktur modern dibangun dan di-scale.

Ringkasan #

• Perbedaan fundamental: Nginx event-driven async vs Apache process-per-connection — ini yang menjelaskan semua perbedaan performa.
• Nginx unggul untuk file statis, koneksi bersamaan tinggi, dan lingkungan cloud/container.
• Apache unggul untuk shared hosting, ekosistem modul yang luas, dan kemudahan .htaccess.
• Nginx tidak mendukung .htaccess — ini disengaja untuk performa, bukan keterbatasan.
• Untuk deployment baru di dedicated server/cloud, Nginx adalah pilihan yang lebih umum direkomendasikan.
• Keduanya bisa dipakai bersamaan: Nginx sebagai front-end untuk file statis, Apache sebagai backend untuk konten dinamis.
• Untuk shared hosting atau CMS yang bergantung .htaccess, Apache masih relevan dan seringkali lebih mudah.

← Sebelumnya: Sejarah & Evolusi   Berikutnya: Arsitektur Event-Driven →