Persyaratan kinerja WordPress bisa bervariasi di antara banyak sekali proyek, tetapi satu hal yang tetap sama adalah—harus cepat.
Image :DigitalOcean
Syarat lain yang otomatis ada adalah—harus ekonomis, sebab kita tidak bisa memakai 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 mendapat banyak kunjungan, konfigurasi server web yang Anda gunakan untuk WordPress mempunyai dampak pribadi pada kinerja situs Anda, mensugesti waktu pemuatan dan stabilitas.
Ketika menentukan server web Anda, ada beberapa pilihan: proyek-proyek yang terkenal yaitu Apache, Nginx, IIS, Caddy, dan Lighttpd. Kami akan membahas Apache dan Nginx dalam panduan ini.
Diperkirakan bahwa jikalau semua internet di dunia digabungkan, 50% traffic web yaitu Apache Server dan Nginx.
Jika Anda pendatang gres dalam topik ini, mungkin Anda sedikit resah 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 yaitu proyek yang sangat mapan, dan keduanya mempunyai 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 yaitu cara keduanya menangani koneksi.
Sederhananya, Apache mengunakan solusi forked threaded, atau keep-alive, yang mempertahankan koneksi terbuka bagi tiap pengguna.
Di sisi lain, Nginx memakai non-blocking event loop, yang menyatukan koneksi yang bekerja secara asinkron melalui proses-proses pekerja.
Karena arsitektur ini, jadinya yaitu proses utas tunggal (single threaded) nginx, dan proses-proses embel-embel tidak di-spawn untuk menangani tiap koneksi baru. Makara 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 cuilan berikutnya dalam panduan ini.
Pertama, mari kita melihat kedua proyek tersebut untuk mendapat citra yang lebih jelas.
Apache
Dimulai tahun 1995 oleh Robert McCool, alumni University of Illinois, yang secara berkelanjutan menyebarkan di bawah Apache Software Foundation semenjak 1999.
Paling luas penggunaannya di Internet semenjak 1996 (default bagi banyak host contohnya para pengguna cPanel).
Menggunakan file .htaccess untuk penulisan ulang URL.
Menggunakan file httpd.conf untuk Konfigurasi Server dengan suatu sintaks yang mirip XML.
WordPress bekerja dengan Apache hampir pribadi di luar kotak, suatu modul PHP semacam mod_php disyaratkan di sini, tetapi tidak banyak lagi yang dibutuhkan untuk menjalankannya.
Apache sangat fleksibel dan mempunyai segudang modul. Umunya mod_rewrite dipakai 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.
Sebagai pengganti Apache, Nginx mempunyai manfaat pengetahuan terhadap jebakan tersembunyi serta gosip kinerja koneksi serentak yang bisa terjadi, dan Nginx mendapat hadiah penuh akan hal ini dengan desain event loop asinkronnya yang sangat cepat.
Untuk konten statis hal ini bekerja sangat cepat. Sedangkan konten dinamis, contohnya PHP, Nginx tidak mempunyai kemampuan untuk memrosesnya dengan modul sebagaimana Apache. Tetapi itu bukan halangan sebab Nginx memakai 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 memakai Apache)
SSL (jika sedang digunakan)
Apache dan Nginx keduanya mendukung php fpm. Ini yaitu manajer FastCGI, suatu forked process manager untuk PHP yang bisa dipakai untuk menyediakan waktu respon yang sangat cepat. Berjalan sebagai daemon di server, ini akan secara orisinil menghasilkan proses seiring dipersyaratkannya.
Mengonfigurasi PHP FPM Dengan Apache
Pengguna Ubuntu dan Debian bisa memasang paket yang disyaratkan dengan aptitude melalui:
Sekarang mulai ulang Apache-nya dan Anda siap untuk mulai
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:
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 memakai 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, sebab 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. ; http://php.net/cgi.fix-pathinfo cgi.fix_pathinfo=0 [...]
Sekarang Anda bisa menyimpan filenya, dan memuat ulang PHP FPM. Lakukan ini melalui:
service php7.0-fpm reload
Terakhir, kita bisa mengecek <? phpinfo(); ?> di dalam peramban untuk mengonfirmasi bahwa kini servernya memakai PHP FPM dengan Nginx.
Melakukan mod_rewrite di Nginx
Nginx tidak memakai file .htaccess, dan untuk penulisan ulang URL pendekatannya jauh lebih sederhana.
Untuk menciptakan blog WordPress Anda bekerja dengan Nginx, tambahkan kode berikut ke cuilan try_files konfigurasi Nginx Anda.
Mulai ulang Nginx dan penulisan ulang URL Anda akan berjalan.
$ service nginx restart
Pengaturan Awal yang Optimal
Anda mempunyai 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 yaitu solusi hebat untuk melayani konten situs web statis dengan static content cache-nya yang kokoh dan cepat.
Static Content Cache
Nginx sangatlah cepat ketika dipakai 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 melaksanakan 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 mirip 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|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 memakai open_file_cache, kita mengaktifkan caching untuk file media statisnya. Kita memutuskan jumlah maksimal file-file yang di-cache dan seberapa usang 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:
Penting:open_file_cache_errors akan meng-cache kesalahan 404 yang sesungguhnya, jadi lebih baik untuk menonaktifkannya jikalau Anda memakai load balancer dalam kaitannya dengan hal ini.
Pool Koneksi PHP-FPM
Dimungkinkan untuk memakai pool yang berbeda bagi tiap WordPress yang berbeda, dan Anda bisa mengalokasikan sumber daya dengan sangat akurat untuk tiap situsnya—bahkan memakai pengguna dan grup yang berbeda untuk tiap pool jikalau dibutuhkan. Konfigurasinya sangat fleksibel.
Anda bisa mengatur beberapa konfigurasi, misalnya:
Dengan ini, Anda bisa memutuskan pilihan konfigurasi PHP-FPM mirip pm.max_children, dan Anda juga bisa memutuskan variabel-variabel environment serta mengatur nama pengguna dan pengaturan grup di sini.
Load Balancer Nginx
Jika Anda akan mendapat banyak traffic maka Anda mungkin ingin mengatur penggunaan load balancer dengan pengaturan php-fpm Anda.
Secara konvensional, kita akan memakai beberapa server upstream back-end, yang semuanya menjalankan mirror blog Anda, dan kemudian menciptakan server lain menjalankan nginx di depannya dan berperan sebagai load balancer dan akan mengarahkan muatannya antar upstream.
Artinya Anda bisa memakai banyak server untuk mendayai blog Anda secara serentak, dan konfigurasi untuk melakukannya relatif mudah.
Contoh konfigurasinya akan tampak mirip 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 mempunyai konfigurasi Nginx tersendiri, mirror wacana bagaimana situsnya sebelum mempunyai load balancer. Nginx akan menentukan server mana yang dipakai untuk tiap permintaan.
Jika salah satu back end kita mempunyai hardisk yang lebih cepat, mirip contohnya 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, jikalau berdasarkan Anda suatu server bisa down atau dikhawatirkan timeout-nya, ada juga pilihan konfigurasi untuk ini:
upstream backend { server backend1.example.com max_fails=3 fail_timeout=15s; server backend2.example.com weight=2; server backend3.example.com weight=4;
Sekarang, dengan konfigurasi ini, sehabis 3 kegagalan atau timeout 15 detik, server tidak akan dipakai 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 memakai 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 rujukan Anda di sini yaitu 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 memakai sarana sumber terbuka apache2nginx untuk menerjemahkan konfigurasi Anda dari Apache ke Nginx.
Ikuti langkah-langkah pemasangan di apache2nginx README, dan sekalinya terpasang Anda akan mempunyai kemampuan untuk memigrasi file-file konfigurasi hanya dengan menjalankan:
$ apache2nginx -f /etc/httpd/conf/httpd.conf
Anda kini 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 yaitu pilihan yang paling terang jikalau 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 berpengaruh dengan Nginx dan PHP-FPM.
Memigrasikan WordPress Anda ke Nginx tidaklah sangat sulit, dan konfigurasi bersama Nginx sangat sederhana dan gampang diakses dibandingkan dengan Apache.
Meskipun modul yang ada tidak sama dengan Apache dan Anda mungkin di awal tidak akrab, Anda akan bisa mendapat penggantinya dalam banyak hal. Jika tidak, sebagai solusi yang bisa diandalkan, Anda selalu bisa proxy server lamanya dengan nginx untuk tujuan ini jikalau diperlukan.
Ada banyak cara untuk mengonfigurasi kedua server, jadi solusi yang manis selalu bisa ditemukan untuk persyaratan apa saja. Untuk ketika ini, kelihatannya Apache akan selalu menjadi pilihan default untuk perangkat lunak hosting cPanel yang ada, sebab alat pengaturan EasyApache yang sepaket dengannya.
Di kemudian hari, mungkin akan ada lebih banyak host yang mengadopsi sarana cPanel Nginx mirip Engintron yang juga menyediakan Nginx pada cPanel.
Untuk ketika ini, jikalau Anda ingin berpindah ke WordPress yang didayai Nginx, Anda akan membutuhkan pengaturan Linux VPN di Digital Ocean, AWS, atau penyedia hosting lainnya.
