Mengira Naikkan memory_limit PHP Bikin Website Lebih Cepat

Website terasa lambat, lalu langkah pertama yang diambil adalah membuka php.ini atau pengaturan PHP di panel hosting dan menaikkan memory_limit dari 128M ke 512M, kadang langsung ke 1G. Asumsinya sederhana: makin besar memori yang "diberikan" ke PHP, makin cepat halaman diproses. Cara kerja PHP tidak seperti itu. memory_limit hanya batas atas, dan di server dengan banyak worker PHP-FPM, nilai yang terlalu besar malah bisa membuat server lebih gampang kehabisan RAM. Pola ini cukup sering muncul di tiket support. Biasanya sumbernya tutorial optimasi WordPress yang menyarankan menaikkan limit sebagai langkah standar. Setelah diubah, situsnya tetap lambat, lalu muncul pertanyaan lanjutan: "Sudah saya naikkan, kok masih sama?"

Apa yang sebenarnya diatur oleh memory_limit

memory_limit adalah jumlah maksimum memori yang boleh dialokasikan oleh satu eksekusi script PHP. Kalau sebuah request mencoba memakai lebih dari batas itu, PHP menghentikan script dan menulis fatal error. Hanya itu fungsinya. Yang penting dipahami: PHP tidak memesan memori sebesar memory_limit di awal. Script yang butuh 30 MB akan memakai sekitar 30 MB, baik limit-nya 128M maupun 1G. Limit tidak mengubah berapa banyak memori yang dibutuhkan script, dan tidak mengubah seberapa cepat kode PHP dieksekusi. Analogi yang lebih pas adalah batas kecepatan di jalan tol. Menaikkan batas dari 80 ke 120 tidak membuat mobil yang mesinnya cuma sanggup 60 jadi lebih cepat. Batas itu baru berpengaruh ketika ada yang mencoba melewatinya.

Kenapa angkanya tidak membuat halaman lebih cepat

Kecepatan sebuah request PHP ditentukan oleh hal lain: berapa lama query database berjalan, berapa banyak kode yang harus dieksekusi, apakah bytecode sudah ada di OPcache, apakah ada panggilan HTTP ke layanan luar yang lambat, dan apakah ada worker PHP-FPM yang kosong untuk menangani request itu. Tidak satu pun dari faktor tersebut berubah ketika memory_limit dinaikkan. Ada satu kasus di mana menaikkan limit terlihat "memperbaiki" sesuatu: request yang sebelumnya gagal karena kehabisan memori sekarang berhasil. Dari sisi pengguna, halaman yang tadinya error atau blank sekarang tampil. Itu memperbaiki error, bukan mempercepat. Kalau halamannya butuh 300 MB memori untuk dirender, biasanya itu tanda ada sesuatu yang perlu diperiksa, misalnya plugin yang memuat ribuan baris data ke array sekaligus atau proses resize gambar berukuran besar. Limit yang terlalu longgar juga bisa menyembunyikan masalah. Script dengan memory leak atau loop yang terus menumpuk data akan berjalan lebih lama sebelum dihentikan. Dengan limit kecil, masalahnya cepat ketahuan lewat error. Dengan limit 1G atau -1 (tanpa batas), script itu bisa terus memakan RAM sampai server yang kena dampaknya.

Masalahnya muncul saat worker PHP-FPM banyak

Di sebagian besar setup modern, PHP dijalankan lewat PHP-FPM. Ada sekumpulan proses worker, dan tiap worker menangani satu request dalam satu waktu. Jumlah maksimum worker di sebuah pool diatur oleh pm.max_children. memory_limit berlaku per proses, bukan untuk seluruh server. Jadi skenario terburuknya kira-kira pm.max_children × memory_limit, ditambah memori dasar tiap proses. Contoh ilustratif dengan angka bulat: VPS dengan RAM 4 GB, satu pool dengan pm.max_children = 20, dan memory_limit = 512M. Di atas kertas, PHP boleh memakai sampai sekitar 10 GB. Selama traffic normal dan script ringan, angka itu tidak pernah tercapai, jadi semuanya terlihat aman. Masalahnya datang saat kondisi tidak normal: traffic naik, bot menyerbu halaman pencarian, atau beberapa admin menjalankan export bersamaan. Beberapa worker sekaligus mengerjakan request berat, dan karena limit-nya longgar, tidak ada yang dihentikan PHP. RAM habis, sistem mulai memakai swap sehingga semuanya melambat drastis, lalu OOM killer kernel mulai mematikan proses. Yang dimatikan sering bukan PHP, tapi proses besar lain seperti MySQL. Gejala lanjutan ini dibahas di How to Spot Memory Pressure on a VPS Before the OOM Killer Hits. Dengan kata lain, memory_limit yang wajar berfungsi sebagai pengaman. Ia memastikan satu request yang bermasalah gagal sendirian, bukan menyeret seluruh server. Ada satu detail lagi. Worker PHP-FPM yang pernah menangani request berat biasanya tidak langsung mengembalikan semua memorinya ke sistem operasi. Proses itu bisa tetap "gemuk" sampai di-restart atau didaur ulang. Inilah salah satu alasan pemakaian RAM PHP-FPM pelan-pelan naik seiring waktu, dan kenapa limit yang besar memperbesar kemungkinan hal ini terjadi.

Kapan memory_limit memang perlu dinaikkan

Patokannya jelas: naikkan limit kalau ada bukti script kehabisan memori, bukan karena situs terasa lambat. Bukti itu berupa fatal error di log. Lokasi log tergantung setup, bisa error_log di direktori situs, log PHP-FPM, atau log yang diatur lewat control panel.

BASH

# Cari error kehabisan memori di log PHP (sesuaikan path dengan setup kamu)
grep -i 'allowed memory size' /path/ke/error_log | tail -n 5

Pesannya kira-kira seperti ini:

TEXT

# contoh format output
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/user/public_html/wp-content/plugins/contoh-plugin/file.php on line 123

Angka pertama adalah limit dalam byte (134217728 byte = 128M). Path di akhir menunjukkan di mana script berhenti. Path itu belum tentu biang masalahnya, karena itu hanya titik di mana alokasi terakhir gagal. Tapi informasi ini cukup untuk mempersempit apakah masalahnya dari plugin, tema, atau proses tertentu. Kalau memang perlu dinaikkan, naikkan secukupnya dan sesempit mungkin cakupannya. Beberapa pendekatan yang biasanya lebih aman daripada menaikkan nilai global:

Untuk task CLI seperti import atau WP-CLI, pakai limit sekali jalan, misalnya php -d memory_limit=512M script.php. Worker web tidak ikut terpengaruh.
Untuk WordPress, area admin sudah punya konstanta WP_MAX_MEMORY_LIMIT yang terpisah dari WP_MEMORY_LIMIT untuk frontend. Proses berat di admin bisa diberi ruang lebih tanpa menaikkan limit untuk semua pengunjung. Konstanta WordPress ini tetap dibatasi oleh apa yang diizinkan server.
Kalau satu situs di server butuh limit besar, atur di level pool situs itu saja, bukan di php.ini global. Caranya tergantung control panel yang dipakai.

Setelah mengubah, pastikan nilai yang berlaku memang yang kamu harapkan. php -i di terminal menampilkan konfigurasi PHP CLI, yang sering membaca php.ini berbeda dari PHP-FPM. Untuk nilai yang dipakai situs, cek lewat phpinfo() dari browser, lalu hapus file itu setelah selesai karena isinya membuka banyak detail server. Sebelum menetapkan angka, lihat juga berapa memori yang dipakai worker saat ini:

BASH

# Pemakaian RAM (RSS, dalam KB) tiap worker PHP-FPM
ps -eo pid,rss,cmd | grep '[p]hp-fpm: pool'

Angka RSS ini sedikit melebih-lebihkan pemakaian sebenarnya, karena ikut menghitung memori yang dibagi antar proses seperti shared memory OPcache. Meski begitu, angka ini cukup untuk memperkirakan rata-rata worker. Dari situ kamu bisa menilai apakah kombinasi pm.max_children dan memory_limit masih masuk akal untuk RAM yang ada.

Yang sebaiknya dicek dulu saat website lambat

Kalau tidak ada error kehabisan memori di log, memory_limit hampir pasti bukan penyebabnya. Di support, urutan pengecekan yang biasanya lebih produktif kira-kira seperti ini. Pertama, lihat apakah lambatnya di semua halaman atau hanya halaman tertentu. Halaman statis yang lambat mengarah ke server atau jaringan. Kalau yang lambat hanya halaman dinamis seperti checkout, pencarian, atau dashboard, biasanya masalahnya di aplikasi atau database. Kedua, cek apakah worker PHP-FPM habis. Kalau semua worker sedang sibuk, request baru harus mengantre, dan dari luar ini terlihat persis seperti "situs lambat". PHP-FPM slow log membantu menunjukkan script mana yang menahan worker paling lama. Ketiga, cek database. Query tanpa index, tabel wp_options dengan banyak data autoload, atau tabel yang terkunci saat backup bisa menahan request jauh lebih lama daripada eksekusi PHP-nya sendiri. Keempat, cek page cache dan OPcache. Halaman yang seharusnya bisa disajikan dari cache tapi selalu dirender ulang oleh PHP akan membebani worker tanpa perlu. OPcache yang penuh juga membuat PHP mengompilasi ulang script terus-menerus. Kelima, cek kondisi server di bawahnya. Di VPS, CPU steal dan I/O wait yang tinggi bisa membuat semuanya lambat meski pemakaian CPU di dalam guest terlihat rendah. Cara membacanya ada di Kenapa VPS Tetap Lemot Padahal Pemakaian CPU Masih Rendah. Terakhir, jangan lupa panggilan ke layanan luar. Plugin yang mengecek lisensi, mengambil feed, atau memanggil API pihak ketiga di setiap page load bisa menahan request beberapa detik setiap kali layanan itu lambat merespons. Anggap memory_limit sebagai pagar pengaman, bukan pedal gas. Biarkan di nilai yang wajar untuk aplikasimu. Naikkan hanya kalau log menunjukkan error "Allowed memory size exhausted", dan kalau bisa naikkan untuk cakupan yang sempit saja. Setiap kali mengubahnya, hitung ulang pm.max_children × memory_limit terhadap RAM yang benar-benar tersedia. Untuk keluhan lambat, mulailah dari worker, database, cache, dan kondisi server, karena di situlah waktu request biasanya habis.