Halo sobat Melanjutkan cerita dari artikel sebelumnya, setelah WAF Nginx berhasil saya pasang di server klien, muncul kendala baru yang tidak terduga. Salah satu klien saya mengelola sebuah blog edukasi koding dan pemrograman. Dua hari setelah WAF terpasang, beliau menghubungi saya karena ada laporan dari pembaca websitenya.

Laporannya begini: pembaca tidak bisa menggunakan kolom pencarian di blog tersebut setiap kali mencari tutorial yang mengandung kata seperti INSERT, SELECT, atau sintaks koding lainnya. Begitu tombol cari diklik, halaman malah menampilkan error penolakan dari server.

Saya langsung sadar bahwa aturan WAF awal yang saya pasang ternyata terlalu “agresif” dan memicu *False Positive*. WAF menganggap pembaca yang sedang mencari tutorial koding sebagai hacker yang sedang mencoba melakukan SQL Injection atau XSS. Bagi sebuah blog edukasi koding, tentu ini sangat mengganggu kenyamanan pengunjung. » Read more

Ada momen di mana seorang pemilik website mendadak diuji kesabarannya. Bayangkan, di saat transaksi atau aktivitas bisnis sedang ramai-ramainya di jam kerja, tiba-tiba website tidak bisa diakses sama sekali. Tampilan layar hanya menunjukkan pesan error “Error Establishing a Database Connection” (koneksi antara sistem website dan tempat penyimpanan data terputus). Kepanikan pun tak terhindarkan, apalagi kalau melihat laporan pengunjung harian sebenarnya terbilang wajar-wajar saja.

Kejadian seperti ini sempat dialami oleh salah satu klien yang datang kepada saya dengan kondisi cemas. Website milik beliau mendadak bertumbangan berulang kali. Setelah ditelusuri lewat log server (catatan riwayat aktivitas harian di dalam sistem server), ternyata server VPS (Virtual Private Server, komputasi server virtual bertipe khusus) kapasitas 1GB RAM (Random Access Memory, memori kerja sementara server) milik klien sedang dibombardir ribuan bot (program otomatis yang berkeliaran di internet) pemindai dari luar negeri yang sengaja mencari celah keamanan WordPress. » Read more

Sobat, penurunan performa server (slowdown) kadang suka bikin bingung, apalagi waktu penggunaan CPU (otak pemrosesan server) dan RAM (memori kerja utama) terpantau masih tenang-tenang aja. Kejadian ini sempat dialami salah satu klien saya pas aktivitas Disk Write I/O (proses penulisan data ke dalam media penyimpanan) mendadak melonjak tajam. Usut punya usut, ternyata Nginx (aplikasi web server) sibuk bikin ribuan temporary file (file simpanan sementara) di dalam folder /var/lib/nginx/fastcgi/.

Saat menelusuri akar masalahnya, fokus saya langsung tertuju pada perbedaan kecepatan akses antar media penyimpanan. Proses baca-tulis data di RAM jauh lebih ngebut dibanding penulisan ke disk storage (piringan atau chip penyimpanan permanen). Ketika Nginx terbiasa menumpuk luapan data dari PHP ke dalam disk sebelum dikirim ke pengunjung, akumulasi jeda waktu pemrosesan inilah yang bikin respon website berasa agak ngadat. Penanganan presisi yang biasa saya terapkan untuk kasus seperti ini adalah mengalihkan seluruh alur data agar diproses murni di RAM, jadi pemilik bisnis nggak perlu pusing lagi mikirin performa situsnya yang melambat.

» Read more

Sobat, kekhawatiran terkait konsumsi RAM (memori kerja utama server) sering kali muncul saat kita hendak memperbesar alokasi buffer di Nginx (aplikasi web server). Seorang klien pernah dengan cemas menanyakan apakah setelan FastCGI buffer (alokasi RAM sementara untuk menampung data dari PHP) sebesar 16×64 KB (1 MB) akan menguras habis memori pada server berkapasitas 3 GB jika ada 200 request (permintaan akses pengunjung) yang masuk secara bersamaan.

Saat mendampingi klien tersebut, saya menjelaskan bagaimana alokasi memori Nginx sebenarnya bekerja. Pengalokasian FastCGI buffer di Nginx pada dasarnya bersifat dinamis (bekerja secara bertahap sesuai kebutuhan riil, bukan mengunci memori di awal). Nginx tidak langsung menyita RAM sebesar 1 MB untuk tiap pengunjung, melainkan hanya mengambil unit buffer 64 KB secara perlahan sesuai ukuran aktual halaman yang dimuat. Dengan pemahaman ini, pemilik bisnis bisa merasa tenang karena server tetap bekerja aman dan efisien tanpa harus khawatir mengenai lonjakan penggunaan memori. » Read more

Sobat, memuat halaman web berukuran besar sering kali menimbulkan hambatan kecepatan (bottleneck) jika server belum dioptimalkan dengan baik. Hal ini dialami oleh seorang klien ketika halaman katalog dan laporan data berukuran sekitar 667 KB terasa kurang responsif saat diakses pengunjung.

Saat saya cek jalur pengiriman data dari backend ke Nginx, akar masalahnya langsung kelihatan. Ada dua hal yang bikin prosesnya tertahan: buffer standar Nginx belum muat menampung file 667 KB di memori RAM, dan data HTML/JSON-nya dikirim secara mentah (polosan) tanpa kompresi. Solusinya cukup simpel: naikkan nilai FastCGI buffer dan aktifkan kompresi Gzip di Nginx supaya ukuran transmisinya bisa dipangkas.
» Read more

Sobat, setelah memahami arti dari peringatan FastCGI buffer di Nginx, pertanyaan berikutnya yang sering muncul adalah bagaimana cara menghentikannya secara permanen. Klien saya pernah menanyakan hal ini karena ingin memastikan file log servernya tetap bersih dan penggunaan disk storage tidak terbuang untuk menulis temporary file.

Saat menganalisis kasus ini, langkah pertama yang saya lakukan adalah memeriksa file konfigurasi Nginx di /etc/nginx/nginx.conf (pusat pengaturan utama web server). Dari situ terlihat bahwa FastCGI buffer (alokasi memori RAM sementara untuk menampung data dari PHP) masih menggunakan nilai bawaan default 64 KB. Padahal, halaman dinamis pada website klien rata-rata berukuran di atas 200 KB. Penanganan presisi yang biasa saya terapkan untuk kendala seperti ini adalah menyesuaikan alokasi FastCGI buffer agar seluruh respon PHP bisa ditampung utuh di RAM, sehingga performa website kembali responsif tanpa membuat pemilik bisnis pusing memikirkan urusan teknis server.
» Read more