Apache vs. Nginx: Kelebihan & Kekurangannya untuk WordPress

() translation by (you can also view the original English article)

Persyaratan kinerja WordPress bisa bervariasi di antara berbagai proyek, tetapi satu hal yang tetap sama adalah—harus cepat.

Syarat lain yang otomatis ada adalah—harus ekonomis, karena kita tidak bisa menggunakan solusi yang butuh banyak sumber daya. Solusinya harus ringkas, tegas, dan bisa diandalkan, dan untuk memaksimalkan penghasilan dari situs Anda, pengeluaran hosting harus ditekan seminimal mungkin.

Jika Anda mengekspektasikan untuk mendapatkan banyak kunjungan, konfigurasi server web yang Anda gunakan untuk WordPress memiliki dampak langsung pada kinerja situs Anda, mempengaruhi waktu pemuatan dan stabilitas.

Ketika memilih server web Anda, ada beberapa pilihan: proyek-proyek yang populer adalah Apache, Nginx, IIS, Caddy, dan Lighttpd. Kami akan membahas Apache dan Nginx dalam panduan ini.

Diperkirakan bahwa jika semua internet di dunia digabungkan, 50% traffic web adalah Apache Server dan Nginx.

Jika Anda pendatang baru dalam topik ini, mungkin Anda sedikit bingung dengan dua tujuan perangkat lunak yang kelihatannya identik—untuk melayani situs web. Saya harap dalam artikel ini bisa memperjelas dua hal berbeda itu dan bagaimana memanfaatkan fitur masing-masing.

Apache dan Nginx adalah proyek yang sangat mapan, dan keduanya memiliki alasan sendiri-sendiri untuk mencapai alasan yang serupa dalam melayani situs WordPress Anda. Meskipun demikian, ketika kita melihat lebih dalam ke desainnya, ada perbedaan utama bagaimana masing-masing server melayani koneksi.

Perbedaannya

Perbedaan utamanya adalah cara keduanya menangani koneksi.

Sederhananya, Apache mengunakan solusi forked threaded, atau keep-alive, yang mempertahankan koneksi terbuka bagi tiap pengguna.

Di sisi lain, Nginx menggunakan non-blocking event loop, yang menyatukan koneksi yang bekerja secara asinkron melalui proses-proses pekerja.

Karena arsitektur ini, hasilnya adalah proses utas tunggal (single threaded) nginx, dan proses-proses tambahan tidak di-spawn untuk menangani tiap koneksi baru. Jadi tiap kali terjadi muatan tinggi, CPU dan RAM tidak akan terbebani dengan pendekatan ini.

Selain arsitektur, ada juga beberapa perbedaan dan nuansa kecil di antara keduanya dalam hal konfigurasi, dan kita akan melihatnya secara lebih detail di bagian berikutnya dalam panduan ini.

Pertama, mari kita melihat kedua proyek tersebut untuk mendapatkan gambaran yang lebih jelas.

Apache

Dimulai tahun 1995 oleh Robert McCool, alumni University of Illinois, yang secara berkelanjutan mengembangkan di bawah Apache Software Foundation sejak 1999.
Paling luas penggunaannya di Internet sejak 1996 (default bagi banyak host misalnya para pengguna cPanel).
Menggunakan sistem pemuatan extensible dynamic module secara luas.
Menggunakan file .htaccess untuk penulisan ulang URL.
Menggunakan file httpd.conf untuk Konfigurasi Server dengan suatu sintaks yang menyerupai XML.

WordPress bekerja dengan Apache hampir langsung di luar kotak, suatu modul PHP semacam mod_php disyaratkan di sini, tetapi tidak banyak lagi yang dibutuhkan untuk menjalankannya.

Apache sangat fleksibel dan memiliki segudang modul. Umunya mod_rewrite digunakan untuk menyediakan penulisan ulang URL untuk menginterpretasikan URL seperti categories.php?id=4 ke /categories/4.

Nginx

Dimulai tahun 2002 oleh Igor Sysoev, seorang insiyur perangkat lunak Rusia, sebagai solusi atas masalah C10k—tantangan bagi server-server web untuk menangani 10.000 koneksi secara bersamaan.
Dirilis secara publik tahun 2004, memenuhi tujuan sebagai arsitektur asinkron, non-blocking, dan event-driven.
Berjalan dengan ringan pada perangkat keras minimal menyediakan kinerja konten statis yang luar biasa.
Sangat responsif pada muatan berat.
Menggunakan file konfigurasi nginx.conf dengan sintaks kurung kurawal semacam JS.
Bisa diperluas dengan modul-modul pihak ketiga.

Sebagai pengganti Apache, Nginx memiliki manfaat pengetahuan terhadap jebakan tersembunyi serta isu kinerja koneksi serentak yang bisa terjadi, dan Nginx mendapatkan hadiah penuh akan hal ini dengan desain event loop asinkronnya yang sangat cepat.

Untuk konten statis hal ini bekerja sangat cepat. Sedangkan konten dinamis, misalnya PHP, Nginx tidak memiliki kemampuan untuk memrosesnya dengan modul sebagaimana Apache. Tetapi itu bukan halangan karena Nginx menggunakan FastCGI untuk melakukannya. FastCGI bekerja sangat baik dalam hubungannya dengan pool koneksi php fpm dan memcache.

Persyaratan WordPress

PHP 7 >
MySQL 5.6 atau Maria DB 10.0 >
mod_rewrite (jika menggunakan Apache)
SSL (jika sedang digunakan)

Apache dan Nginx keduanya mendukung php fpm. Ini adalah manajer FastCGI, suatu forked process manager untuk PHP yang bisa digunakan untuk menyediakan waktu respon yang sangat cepat. Berjalan sebagai daemon di server, ini akan secara asli menghasilkan proses seiring dipersyaratkannya.

Mengonfigurasi PHP FPM Dengan Apache

Pengguna Ubuntu dan Debian bisa memasang paket yang disyaratkan dengan aptitude melalui:

1	sudo apt-get -y install libapache2-mod-fastcgi php7.0-fpm php7.0

Sekarang aktifkan modulnya di apache:

1	a2enmod actions fastcgi alias

Lalu, dalam file konfigurasi /etc/apache2/conf-available/php7.0-fpm.conf, tambahkan kode berikut:

<IfModule mod_fastcgi.c>
    AddHandler php7-fcgi .php
    Action php7-fcgi /php7-fcgi
    Alias /php7-fcgi /usr/lib/cgi-bin/php7-fcgi
    FastCgiExternalServer /usr/lib/cgi-bin/php7-fcgi -socket /var/run/php/php7.0-fpm.sock -pass-header Authorization
</IfModule>

Demikian pula di VirtualHost Anda untuk WordPress (default path /etc/apache2/sites-available/000-default.conf), tambahkan kode berikut:

<Directory /usr/lib/cgi-bin>
    Require all granted
</Directory>
<IfModule mod_fastcgi.c>
    SetHandler php7-fcgi .php
    Action php7-fcgi /php7-fcgi virtual
    Alias /php7-fcgi /usr/lib/cgi-bin/php7-fcgi
    FastCgiExternalServer /usr/lib/cgi-bin/php7-fcgi -socket /var/run/php/php7.0-fpm.sock -pass-header Authorization
</IfModule>

Sekarang mulai ulang Apache-nya dan Anda siap untuk mulai

1	systemctl restart apache2.service

Buat suatu file <?php phpinfo(); ?> dan cari di peramban Anda. Sekarang PHP akan melayani dengan FPM.

Sekarang cek blog WordPress Anda. Sudah melihat ada perbedaan?

Mengonfigurasi PHP FPM Dengan Nginx

Pengguna Ubuntu dan Debian bisa memasang paketnya dengan cara berikut:

1	apt-get -y install php7.0-fpm

Sekarang, di dalam file konfigurasi Anda (default /etc/nginx/sites-available/default) di server block, Anda harus menambahkan konfigurasi FastCGI sebagai berikut:

server {
...
 location / {
    # use try files to try and serve the file
    try_files $uri $uri/ =404;
 }
 
 # PHP FPM Configuration
 location ~ \.php$ {
    include snippets/fastcgi-php.conf;

    # Connect via socket
    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
 }
 
 # deny apache .htaccess requests
 location ~ /\.ht {
  deny all;
 }
 ...
 }

Berikut ini kita menggunakan snippet dari Nginx untuk mengatur parameter-parameter CGI dan memasukkan fastcgi ke koneksi soket.

Berikutnya, pastikan Anda mengatur cgi.fix_pathinfo=0 di php ini, karena pengaturan default memecah konfigurasinya. Sunting /etc/php/7.0/fpm/php.ini dan tetapkan:

[...]
; cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI.  PHP's
; previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok
; what PATH_INFO is.  For more information on PATH_INFO, see the cgi specs.  Setting
; this to 1 will cause PHP CGI to fix its paths to conform to the spec.  A setting
; of zero causes PHP to behave as before.  Default is 1.  You should fix your scripts
; to use SCRIPT_FILENAME rather than PATH_TRANSLATED.
; https://php.net/cgi.fix-pathinfo
cgi.fix_pathinfo=0
[...]

Sekarang Anda bisa menyimpan filenya, dan memuat ulang PHP FPM. Lakukan ini melalui:

1	service php7.0-fpm reload

Terakhir, kita bisa mengecek <? phpinfo(); ?> di dalam peramban untuk mengonfirmasi bahwa sekarang servernya menggunakan PHP FPM dengan Nginx.

Melakukan mod_rewrite di Nginx

Nginx tidak menggunakan file .htaccess, dan untuk penulisan ulang URL pendekatannya jauh lebih sederhana.

Untuk membuat blog WordPress Anda bekerja dengan Nginx, tambahkan kode berikut ke bagian try_files konfigurasi Nginx Anda.

1	location / {
2	index index.php index.html index.htm;
3	try_files $uri $uri/ /index.php?q=$uri&$args;
4	}

Jika Anda menggunakan suatu direktori untuk blog WordPress Anda, silakan tetapkan yang berikut ini:

1	location /wordpress/ {
2	try_files $uri $uri/ /index.php?q=$uri&$args;
3	}

Mulai ulang Nginx dan penulisan ulang URL Anda akan berjalan.

1	$ service nginx restart

Pengaturan Awal yang Optimal

Anda memiliki banyak pilihan untuk mengoptimalkan WordPress melalui caching pada server melalui memcache, varnish dan juga tingkat aplikasi WordPress dengan plugin yang akan memudahkan Anda dalam mengaksesnya.

Meskipun demikian, apa yang diberikan Nginx kepada Anda adalah solusi hebat untuk melayani konten situs web statis dengan static content cache-nya yang kokoh dan cepat.

Static Content Cache

Nginx sangatlah cepat ketika digunakan sebagai static content cache, dan di sinilah penggunaanya sungguh sangat hebat dalam konteks WordPress dan kiriman blog dengan banyak gambar. Anda bisa melayani CSS, JS, dan gambar Anda semua melalui server Nginx yang berjalan untuk kebutuhan-kebutuhan ini saja.

Selalu lebih baik untuk melakukan ini dengan cookie-less domain sehingga kontennya akan benar-benar di-cache oleh peramban (karena tidak sebisa cookie untuk di-cache-kan), maka penggunaan subdomain seperti images.myblog.com atau static.myblog.com akan ideal.

Blok lokasi untuk konfigurasi subdomain statis ini akan terlihat sebagaimana berikut:

    location ~* ^.+\.(?:css|cur|js|jpe?g|gif|htc|ico|png|html|xml|otf|ttf|eot|woff|svg)$ {
        access_log off;
        expires 30d;
        tcp_nodelay off;
        ## Set the OS file cache.
        open_file_cache max=3000 inactive=120s;
        open_file_cache_valid 45s;
        open_file_cache_min_uses 2;
        open_file_cache_errors off;
    }

Dengan menggunakan open_file_cache, kita mengaktifkan caching untuk file media statisnya. Kita menetapkan jumlah maksimal file-file yang di-cache dan seberapa lama dengan open_file_cache max=3000 inactive=120s;

Jika Anda inngin mengatur caching untuk keseluruhan proyek, tambahkan saja empat baris berikut di konfigurasi nginx.conf Anda:

1	open_file_cache max=10000 inactive=5m;
2	open_file_cache_valid 2m;
3	open_file_cache_min_uses 1;
4	open_file_cache_errors on;

Penting: open_file_cache_errors akan meng-cache kesalahan 404 yang sesungguhnya, jadi lebih baik untuk menonaktifkannya jika Anda menggunakan load balancer dalam kaitannya dengan hal ini.

Pool Koneksi PHP-FPM

Dimungkinkan untuk menggunakan pool yang berbeda bagi tiap WordPress yang berbeda, dan Anda bisa mengalokasikan sumber daya dengan sangat akurat untuk tiap situsnya—bahkan menggunakan pengguna dan grup yang berbeda untuk tiap pool jika dibutuhkan. Konfigurasinya sangat fleksibel.

Anda bisa mengatur beberapa konfigurasi, misalnya:

1	/etc/php-fpm.d/family-site.conf
2	/etc/php-fpm.d/travel-blog.conf
3	/etc/php-fpm.d/cooking-recipes.conf

Dalam tiap-tiap yang berikut ini, kita bisa menetapkan banyak konfigurasi seperti itu:

[site]
listen = 127.0.0.1:9000
user = user
group = websites
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slowlog-site.log
listen.allowed_clients = 127.0.0.1
pm = dynamic
pm.max_children = 5
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200
listen.backlog = -1
pm.status_path = /status
request_terminate_timeout = 120s
rlimit_files = 131072
rlimit_core = unlimited
catch_workers_output = yes
env[HOSTNAME] = $HOSTNAME
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp

Dengan ini, Anda bisa menetapkan pilihan konfigurasi PHP-FPM seperti pm.max_children, dan Anda juga bisa menetapkan variabel-variabel environment serta mengatur nama pengguna dan pengaturan grup di sini.

Load Balancer Nginx

Jika Anda akan mendapatkan banyak traffic maka Anda mungkin ingin mengatur penggunaan load balancer dengan pengaturan php-fpm Anda.

Secara konvensional, kita akan menggunakan beberapa server upstream back-end, yang semuanya menjalankan mirror blog Anda, dan kemudian membuat server lain menjalankan nginx di depannya dan berperan sebagai load balancer dan akan mengarahkan muatannya antar upstream.

Artinya Anda bisa menggunakan banyak server untuk mendayai blog Anda secara serentak, dan konfigurasi untuk melakukannya relatif mudah.

Contoh konfigurasinya akan tampak seperti ini. Pertama kita memulai dengan suatu modul upstream:

upstream backend  {
  server backend1.example.com;
  server backend2.example.com;
  server backend3.example.com;
}

Di sini, tiap backend1.example.com memiliki konfigurasi Nginx tersendiri, mirror tentang bagaimana situsnya sebelum memiliki load balancer. Nginx akan memilih server mana yang digunakan untuk tiap permintaan.

Jika salah satu back end kita memiliki hardisk yang lebih cepat, seperti misalnya SSD, atau secara geografis lebih dekat ke basis pengguna utama Anda, pembobotannya bisa diatur sebagai berikut:

upstream backend  {
  server backend1.example.com weight=1;
  server backend2.example.com weight=2;
  server backend3.example.com weight=4;
}

Sebagai tambahan, jika menurut Anda suatu server bisa down atau dikhawatirkan timeout-nya, ada juga pilihan konfigurasi untuk ini:

1	upstream backend {
2	server backend1.example.com max_fails=3 fail_timeout=15s;
3	server backend2.example.com weight=2;
4	server backend3.example.com weight=4;

Sekarang, dengan konfigurasi ini, setelah 3 kegagalan atau timeout 15 detik, server tidak akan digunakan lagi oleh load balancer. Jika Anda berharap untuk secara manual menandai servernya sebagai tidak aktif, tambahkan kata kunci down, misalnya server backend3.example.com down;.

Berikutnya kita harus memasukkannya ke server melalui proxy dengan menggunakan upstream backend yang telah ditetapkan sebelumnya:

 server {
  location / {
    proxy_pass  http://backend;
  }
}

Sekarang mulai ulang server Anda dengan service nginx restart, dan Anda menjalankan versi situs Anda yang load-balanced!

Yang terakhir di topik ini, juga sebagai referensi Anda di sini adalah suatu panduan nginx pada pelayanan konten statis dan opsi konfigurasi terbaik. Perhatikan penggunaan tcp_nopush dan sendfile untuk Mp3, sebagai contoh:

Migrasi Apache ke Nginx

Selain membaca manual Nginx dan mencoba melakukannya sendiri, Anda bisa menggunakan sarana sumber terbuka apache2nginx untuk menerjemahkan konfigurasi Anda dari Apache ke Nginx.

Ikuti langkah-langkah pemasangan di apache2nginx README, dan sekalinya terpasang Anda akan memiliki kemampuan untuk memigrasi file-file konfigurasi hanya dengan menjalankan:

1	$ apache2nginx -f /etc/httpd/conf/httpd.conf

Anda sekarang bisa mengecek konfigurasinya dan mencobanya pada pemasangan Nginx Anda. Penerjemahannya mungkin tidak sempurna, tetapi cukup menjadi dasar bagi Anda untuk memulai.

Kesimpulan

Untuk kecepatan dan kinerja, Nginx adalah pilihan yang paling jelas jika dihadapkan dengan Apache, tetapi tidak berarti Apache tidak bisa menangani sejumlah traffic. Jika Anda berencana ke halaman depan Reddit kapan saja dalam waktu dekat, Anda harus mencari solusi yang lebih kuat dengan Nginx dan PHP-FPM.

Memigrasikan WordPress Anda ke Nginx tidaklah sangat sulit, dan konfigurasi bersama Nginx sangat sederhana dan mudah diakses dibandingkan dengan Apache.

Meskipun modul yang ada tidak sama dengan Apache dan Anda mungkin di awal tidak akrab, Anda akan mampu mendapatkan penggantinya dalam banyak hal. Jika tidak, sebagai solusi yang bisa diandalkan, Anda selalu bisa proxy server lamanya dengan nginx untuk tujuan ini jika diperlukan.

Ada banyak cara untuk mengonfigurasi kedua server, jadi solusi yang bagus selalu bisa ditemukan untuk persyaratan apa saja. Untuk saat ini, kelihatannya Apache akan selalu menjadi pilihan default untuk perangkat lunak hosting cPanel yang ada, karena alat pengaturan EasyApache yang sepaket dengannya.

Di kemudian hari, mungkin akan ada lebih banyak host yang mengadopsi sarana cPanel Nginx seperti Engintron yang juga menyediakan Nginx pada cPanel.

Untuk saat ini, jika Anda ingin berpindah ke WordPress yang didayai Nginx, Anda akan membutuhkan pengaturan Linux VPN di Digital Ocean, AWS, atau penyedia hosting lainnya.