Ketika Pagar Besi Server Jebol karena Banjir Pengunjung

Malam itu, adalah malam peluncuran sebuah buku. Katakanlah judulnya, “Kritik Pedas untuk Penguasa Digital” (sebuah judul fiktif, tentu saja, namun dengan vibe yang sama dengan genre Buku Mojok). Kami sudah siap. Server kami sudah dipanaskan. Kami tahu bukunya akan booming. Tapi kami tidak tahu seberapa gila sambutannya.

Tepat pukul 00.00 WIB, notifikasi berbunyi nyaring. Bukan notifikasi penjualan, tapi notifikasi kiamat kecil: CPU Utilization: 100%. Alert Level: Critical.

Suhu ruangan kantor terasa dingin, tapi punggung saya basah. Monitor yang biasanya menampilkan grafik bandwidth yang tenang, kini menyerupai garis EKG pasien dengan serangan jantung parah.

Kami telah gagal. Bukan dalam menjual buku, tapi dalam menjalankan janji digital: Akses tanpa batas.

📉 Babak I: Diagnosa Cepat di Tengah Kekacauan (Mengapa Server Menjerit?)

Ketika CPU server Anda menyentuh 100% dan tidak turun, itu bukan lagi masalah lambat; itu masalah kematian instan. Server Anda sibuk, sangat sibuk, tetapi sibuk melakukan tugas yang sangat tidak efisien.

Apa yang terjadi pada server e-commerce seperti Mojok Store saat itu?

1. Masalah PHP-FPM: Drowning in Requests

Server kami, seperti kebanyakan stack modern, menggunakan Nginx sebagai reverse proxy dan PHP-FPM (FastCGI Process Manager) untuk mengolah skrip PHP yang menjalankan backend toko (misalnya, WordPress/WooCommerce).

Masalahnya, kami hanya mengatur pm.max_children PHP-FPM kami terlalu konservatif—hanya 50 proses anak, dengan asumsi setiap proses membutuhkan 80MB RAM.

Analisis Cakrabirawa: Setiap kali pengunjung memuat halaman (terutama halaman produk yang kompleks), FPM membuat child process. Dengan 5.000 pengunjung serentak, 50 proses anak itu habis dalam hitungan detik. Permintaan baru harus mengantri, dan karena antrian sangat panjang, timeout terjadi, pengguna mencoba me-refresh, dan siklus CPU-killing berulang. CPU melonjak 100% karena mengelola antrian dan konteks switching, bukan karena pemrosesan yang efisien.

2. Kueri Database yang “Liar” (The Wild Query)

Kami mencurigai salah satu bagian kode checkout atau widget buku terlaris. Kami segera mengakses Database Monitoring Tool (kami menggunakan Percona Monitoring and Management).

Ternyata, ada kueri ke database MySQL (MariaDB) yang berjalan selama 15 detik. Kueri itu mencari produk yang “paling sering dilihat dalam 7 hari terakhir” tanpa caching yang memadai.

Analisis Cakrabirawa: Dalam kondisi normal, kueri 15 detik itu buruk. Dalam kondisi 5.000 request per menit, kueri yang sama dieksekusi ratusan kali per detik. Ini membebani core CPU database hingga maksimal, membuat proses PHP-FPM yang menunggu hasil kueri juga ikut menumpuk dan memakan CPU. Database adalah leher botol (bottleneck) yang sangat kejam.

3. Sesi PHP yang Menumpuk (The File I/O Killer)

Kami menggunakan sesi PHP berbasis file default. Ketika ribuan pengguna masuk, PHP harus menulis dan membaca ribuan file sesi kecil ke disk (/tmp).

Analisis Cakrabirawa: CPU 100% bukan hanya karena perhitungan, tetapi juga karena I/O Wait. Server sibuk menunggu disk untuk menulis dan membaca data sesi. Di cloud sekalipun, I/O throughput memiliki batas. Ini adalah silent killer yang sering diabaikan.

Babak II: Strategi Cakrabirawa: Pembenahan Kedaulatan Digital

Kami tidak punya waktu untuk re-code seluruh website. Strategi kami adalah tiga lapis pertahanan (Front-End Caching, PHP Optimization, Database Offloading).

A. Pertahanan Lapis Pertama: Front-End Caching (The Quick Fix)

Tujuan: Menghentikan permintaan agar tidak menyentuh PHP sama sekali.

1. Varnish Cache/Nginx FastCGI Cache: Kami segera memverifikasi dan menyesuaikan konfigurasi full-page caching kami. Untuk halaman produk (yang sering diakses tetapi jarang di-update), kami meningkatkan waktu Time-to-Live (TTL) menjadi 5 menit.
   

   Tindakan Kritis: Kami membuat pengecualian ketat untuk keranjang belanja dan halaman checkout. Halaman-halaman ini TIDAK BOLEH di-cache. Kami memastikan cookie sesi WooCommerce (woocommerce_items_in_cart, wp_woocommerce_session) akan mem-bypass cache Varnish.

2. CDN (Content Delivery Network): Memastikan semua aset statis (gambar sampul buku, CSS, JavaScript) di-offload sepenuhnya ke CDN seperti Cloudflare. Ini mengurangi 80% beban bandwidth dan CPU server kami.

B. Pertahanan Lapis Kedua: PHP-FPM & OpCache Tuning (The PHP Hammer)

Karena CPU masih tinggi, kami tahu PHP-FPM masih harus bekerja. Kami harus membuatnya lebih kuat dan lebih cepat.

1. Mengatur Ulang pm.max_children:Kami mengalokasikan RAM tambahan. Dari 16GB RAM server kami, kami mengestimasikan 4GB untuk OS dan database. Sisa 12GB. Dengan asumsi proses PHP terberat membutuhkan 128MB:
   

   Kami menaikkan pm.max_children menjadi 100. Kami juga menaikkan pm.min_spare_servers dan pm.max_spare_servers untuk memastikan selalu ada proses yang siap sedia. Kenaikan ini langsung mengurangi kemacetan antrian.

2. Memperkuat OpCache:Kami memeriksa php.ini dan memastikan konfigurasi OpCache maksimal:
   • opcache.enable=1 (Wajib!)
   • opcache.memory_consumption=256 (MB)
   • opcache.revalidate_freq=0 (Di production, kami set nol agar PHP tidak menghabiskan CPU untuk memeriksa perubahan file pada setiap request. Kami menggunakan deployment script untuk clear cache secara manual saat update kode).
3. Memindahkan Sesi ke Memori (Redis):Ini adalah langkah krusial untuk mengatasi I/O Wait. Kami mengubah handler sesi di php.ini:

   session.save_handler = redis
   session.save_path = "tcp://127.0.0.1:6379"

   1. Dengan memindahkan sesi dari disk ke Redis (yang menyimpan data di RAM), disk I/O untuk sesi hampir nol, dan responsivitas CPU meningkat signifikan.

   C. Pertahanan Lapis Ketiga: Database Offloading (The Final Blow)

   Setelah PHP lebih cepat, kami harus menangani kueri 15 detik yang liar itu.

   1. Redis Object Caching: Kami segera mengaktifkan plugin Object Caching (menggunakan driver Redis). Ini menyimpan hasil dari kueri database yang kompleks dan berulang di dalam RAM server database/tersendiri.
      

      Aksi Kritis: Kueri buku terlaris yang lambat itu (yang dipicu oleh fungsi WooCommerce) kini dilayani dari RAM Redis alih-alih harus menghitung ulang setiap kali. Beban CPU database turun drastis.

   2. Indeks Database: Untuk kueri yang memang harus berjalan, kami bekerja cepat membuat indeks yang hilang pada kolom-kolom metadata produk (wp_postmeta) yang sering dijadikan filter. Indeks adalah daftar isi bagi database. Tanpa itu, database harus membaca setiap baris (Full Table Scan), menghabiskan CPU.

   Epilog: Senja Menyingsing dan Ketenangan Sang Panglima

   Setelah serangkaian penyesuaian yang tegang dan memakan waktu hampir dua jam, grafik di monitor saya mulai menunjukkan warna biru yang menenangkan.

   CPU Server turun dari 100% menjadi 25-35% (sekarang bekerja secara efisien) meskipun volume lalu lintas masih tinggi. Antrian PHP-FPM kosong. Kecepatan response time (TTFB) situs turun dari 12 detik menjadi kurang dari 500 milidetik.

   Kami, tim Cakrabirawa Digital, tahu bahwa pertarungan tidak pernah berakhir. Lonjakan trafik akan selalu datang, didorong oleh sebuah tweet jenaka dari penulis favorit atau endorsement mendadak dari tokoh publik.

   Pelajaran yang kami dapat, yang harus diingat oleh setiap penjaga kedaulatan digital:

   Jangan pernah percaya pada server yang diam. CPU yang 10% di malam hari adalah waktu terbaik untuk mempersiapkan diri menghadapi CPU 100% di tengah hari. Optimasi bukanlah pengeluaran, melainkan asuransi bisnis. Kekuatan sejati terletak pada kemampuan caching, manajemen proses PHP-FPM yang cerdas, dan offloading beban ke RAM (melalui Redis/Memcached) daripada membiarkan CPU dan disk berjuang sendirian.

   Kami menyeruput kopi yang sudah dingin, menyisakan pahitnya adrenalin yang baru saja berlalu. Mojok Store kembali tegak. Penjualan terus mengalir. Dan tugas Cakrabirawa Digital, kini, kembali ke mode siaga—mengawasi setiap detak jantung server, menunggu isyarat lonjakan berikutnya.