Cara Setting PHP 8.3 aaPanel untuk WordPress di VPS + Benchmark

Setting PHP aaPanel WordPress VPS perlu berangkat dari pengukuran, bukan menyalin angka memory_limit atau pm.max_children milik server lain. Catat beban awal dan ukur RAM worker PHP-FPM. Lalu tentukan anggaran resource, ubah satu kelompok parameter, dan ulangi benchmark dengan workload yang sama.

Dua VPS dengan 4 GB RAM dapat memerlukan konfigurasi berbeda. Satu situs dengan banyak request dinamis dapat membebani PHP secara berat. Pekerjaan WP-Cron, AJAX, REST API, dan aktivitas wp-admin pun lebih menuntut daripada belasan situs yang memakai full-page cache.

Lingkungan rujukan memakai Ubuntu 22.04, aaPanel, Nginx sebagai proxy, Apache, PHP 8.3 melalui PHP-FPM, MariaDB, Redis, dan WordPress. Pada stack ini, Nginx menerima koneksi publik lalu meneruskan request dinamis ke Apache dan PHP-FPM. Anda dapat memakai metodenya pada stack lain. Namun nama service, lokasi file, process manager, dan parameter harus mengikuti stack tersebut.

Alur Setting PHP 8.3 aaPanel yang Dapat Diuji

Urutan kerjanya ialah spesifikasi VPS → benchmark hardware → benchmark WordPress → ukur worker → hitung anggaran PHP-FPM. Kemudian ubah konfigurasi, muat ulang service, dan jalankan benchmark kedua. Alur ini mencegah perubahan PHP menutupi hambatan pada disk, database, proses latar, atau CPU VPS.

Dokumentasi Multi-WebServer Hosting aaPanel menempatkan Nginx pada port 80/443 dan Apache pada 8288/8290 dalam mode proxy. aaPanel mengelola PHP untuk Nginx/Apache lewat antarmuka PHP 8.3 di App Store. OpenLiteSpeed memakai LSPHP yang berbeda dari PHP-FPM pada tutorial ini.

Sebelum menyentuh pengaturan, buat cadangan konfigurasi situs dan database. Panduan backup database WordPress dapat menjadi rujukan. Namun pasangkan salinan database dengan backup file dan konfigurasi virtual host agar pemulihan tidak setengah jadi.

Catat Baseline VPS dan Workload WordPress

Baseline harus merekam kondisi mesin serta pola request, bukan sekadar jumlah situs. Tulis CPU, RAM, storage, swap, web server, versi PHP, database, Redis, dan jenis cache. Tambahkan jumlah situs, pekerjaan cron, aktivitas pengguna login, endpoint AJAX atau REST, serta waktu pengujian. Kemudian, pakai catatan waktu untuk menjelaskan perbedaan beban antara jam sepi dan periode traffic puncak.

Traffic harian tidak menjelaskan concurrency. Pageview besar yang tersebar dan tersaji dari cache dapat tetap ringan. Sebaliknya, lonjakan pengguna login dapat memicu request PHP, query database, serta panggilan API luar secara bersamaan.

Jadi, jumlah plugin tidak dapat menjadi rumus kapasitas. Puluhan plugin kecil dapat memakai resource rendah. Sementara, beberapa plugin lain mungkin menjalankan query berat, autoload besar, background job, page builder, atau request jaringan pada setiap kunjungan.

Benchmark VPS Sebelum Mengubah PHP

Benchmark hardware berguna untuk menemukan hambatan yang sudah ada sebelum PHP menerima beban. sysbench menyediakan pengujian CPU dan memory dengan statistik rate serta latency, sedangkan fio cocok untuk pengujian I/O yang terkontrol.

Ukur CPU, Memory, RAM, Swap, dan Load

Jalankan pengujian CPU satu thread dan beberapa thread agar perbedaan kinerja per-core terlihat. Setelah itu, rekam memory throughput, kondisi RAM, swap, load average, serta aktivitas swap masuk dan keluar.

sysbench cpu --threads=1 --time=30 run
sysbench cpu --threads=2 --time=30 run
sysbench memory --threads=1 --time=30 run

free -h
uptime
vmstat 1

Catat events per second, average latency, persentil ke-95, available memory, pemakaian swap, dan kolom si/so dari vmstat. Bila mesin sudah aktif menukar halaman memori ke swap saat idle atau traffic normal, menambah worker PHP akan memperbesar tekanan, bukan mempercepat WordPress.

Uji Storage Tanpa Mengganggu Database

Gunakan fio dengan file uji, ukuran, durasi, pola baca-tulis, dan kedalaman antrean yang Anda dokumentasikan. Tes sequential dan random menjawab pertanyaan berbeda; WordPress serta database juga tidak identik dengan satu pola I/O sintetis.

Namun pengujian disk dapat memenuhi bandwidth storage dan menaikkan latency database. Jalankan di staging atau jendela sepi, pakai file khusus yang boleh dihapus, pantau service, lalu hentikan tes bila error, swap, atau load meningkat tajam.

Benchmark WordPress di VPS: Pisahkan Cached dan Dinamis

Pengujian homepage anonim sering mengukur cache, Nginx, atau CDN, bukan PHP-FPM. Buat skenario terpisah untuk halaman cached dan halaman yang melewati full-page cache. Uji wp-admin, pengguna login, serta endpoint AJAX atau REST dengan wrk atau tool setara yang Anda pahami.

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}\nTotal: %{time_total}\n' https://example.com/

wrk -t2 -c10 -d30s https://example.com/

Kemudian, ulangi request beberapa kali. Simpan RPS, average latency, p95, timeout, error, CPU, RAM, swap, jumlah worker aktif, serta endpoint target. Jangan bandingkan RPS dua situs sebagai skor mutlak karena tema, plugin, query, cache, data, dan pekerjaan request berbeda.

Jangan mengirim load test agresif ke server produksi. Awali dengan concurrency rendah pada situs milik sendiri, lalu naikkan perlahan. Pakai staging bila tersedia dan hentikan tes ketika waktu respons atau resource melewati ambang operasional Anda.

Ukur RAM Worker PHP WordPress di VPS

memory_limit adalah batas memori yang boleh dialokasikan satu script PHP; nilai itu bukan reservasi tetap untuk setiap worker. Sepuluh worker dengan memory_limit = 256M tidak otomatis memakai 2,5 GB. Namun limit besar memperlebar dampak ketika banyak request berat mencapai konsumsi tinggi secara bersamaan.

Ukur resident set size atau RSS worker saat idle, traffic normal, wp-admin, request berat, dan pekerjaan latar. Nama proses dapat berbeda, maka perintah kedua lebih lentur untuk instalasi aaPanel.

ps -ylC php-fpm --sort:rss
ps -eo pid,ppid,user,rss,%mem,%cpu,args | grep '[p]hp-fpm'

Ambil sampel worker pada beban normal sampai berat, bukan worker terkecil. Lalu kurangi total RAM dengan konsumsi OS, aaPanel, Nginx, Apache, MariaDB, Redis, cron, dan proses sistem. Sisihkan ruang filesystem cache serta cadangan lonjakan; sisa konservatif menjadi budget PHP-FPM.

Rumus Awal pm.max_children dan Batas CPU

Untuk rumus awal, bagi budget RAM PHP-FPM dengan RAM worker pada workload representatif. Hasilnya hanya batas teoretis memori. CPU, waktu eksekusi request, koneksi database, antrean, dan lonjakan beban masih dapat menurunkan angka yang aman.

Asumsi simulasi
RAM VPS                  = 4.096 MB
Budget aman PHP-FPM      = 1.200 MB
Worker normal-berat      = 80 MB

1.200 / 80 = 15 worker teoretis

Pada simulasi itu, 15 belum menjadi rekomendasi. VPS 2 vCPU mungkin memiliki RAM untuk 15 worker, tetapi CPU belum tentu sanggup menjalankan request berat serentak. Context switching, CPU 100%, antrean database, dan p95 latency dapat memburuk lebih cepat daripada RPS bertambah.

Pilih Process Manager PHP aaPanel

Manual PHP-FPM menyediakan tiga mode: static, dynamic, dan ondemand. Mode static mempertahankan jumlah child sesuai pm.max_children; dynamic mengatur worker aktif lewat nilai start serta spare; ondemand membuat worker ketika request datang.

dynamic merupakan baseline yang masuk akal untuk banyak instalasi WordPress aktif, tetapi ia bukan pemenang universal. VPS kecil dengan situs sepi dapat menguji ondemand, sedangkan static menuntut data workload yang jauh lebih matang.

Arti Parameter FPM yang Perlu Diukur

• pm.max_children: batas request simultan yang dapat dilayani pool.
• pm.start_servers: worker awal pada mode dynamic.
• pm.min_spare_servers: batas bawah worker idle pada mode dynamic.
• pm.max_spare_servers: batas atas worker idle pada mode dynamic.
• pm.max_requests: jumlah request sebelum worker didaur ulang.
• request_terminate_timeout: batas waktu sebelum worker menghentikan request.
• request_slowlog_timeout: pemicu backtrace request lambat ke slow log.

Nilai terlalu kecil dapat membentuk antrean walau CPU dan RAM masih longgar. Nilai terlalu besar dapat memenuhi RAM, membuat CPU terus penuh, dan memperbanyak koneksi database. Pantau pula swap, OOM kill, latency, serta error.

pm.max_requests mendaur ulang worker setelah sejumlah request dan dapat membatasi pertumbuhan memori pada proses yang hidup lama. Namun angka universal tidak ada: lihat tren RSS worker, biaya spawn, error log, dan kestabilan aplikasi sebelum menetapkan nilainya.

Gunakan Status Page dan Slow Log Sebelum Upgrade VPS

Status PHP-FPM dapat menampilkan listen queue, worker aktif dan idle, max children reached, slow requests, serta memory peak. Dokumentasi status page PHP-FPM juga meminta operator membatasi endpoint status dari akses publik.

Slow log memberi backtrace ketika request melewati request_slowlog_timeout. Dari sana Anda dapat menemukan pool yang kekurangan worker. Anda pun bisa melihat plugin, tema, query, pekerjaan cron, atau API luar yang menahan worker terlalu lama.

request_slowlog_timeout = 5s
slowlog = /path/yang-terproteksi/php-fpm-slow.log
request_terminate_timeout = 0

Nilai 5s di atas hanyalah contoh konfigurasi untuk memulai observasi, bukan standar semua situs. Pilih ambang dari SLA dan distribusi latency aplikasi. Simpan log di luar akses web, lalu rotasi file agar disk tidak penuh.

Upgrade CPU atau RAM dapat menambah kapasitas, tetapi tidak memperbaiki query buruk atau panggilan jaringan yang menggantung. Bila kapasitas server masih longgar dan slow log menunjuk fungsi yang sama berulang kali, perbaiki aplikasi sebelum menambah pm.max_children.

Atur php.ini dan Batas Memori WordPress

Parameter php.ini yang relevan meliputi memory_limit, max_execution_time, max_input_time, max_input_vars, upload_max_filesize, post_max_size, dan max_file_uploads. Naikkan parameter setelah kebutuhan nyata terlihat dari error, ukuran unggahan, formulir, proses impor, atau durasi pekerjaan yang sah.

Menurut memory_limit pada manual PHP, nilai tersebut membatasi memori yang boleh dialokasikan satu script. Membesarkannya tidak membuat WordPress lebih cepat; ia hanya memberi ruang lebih luas kepada request, termasuk request bermasalah.

Dokumentasi WordPress menjelaskan bahwa WP_MEMORY_LIMIT meminta batas untuk operasi biasa. WP_MAX_MEMORY_LIMIT melayani pekerjaan backend yang lebih berat. WordPress dapat mencoba menaikkan limit ketika PHP mengizinkannya, tetapi konstanta itu tidak dapat menembus batas server.

define( 'WP_MEMORY_LIMIT', 'nilai-terukur' );
define( 'WP_MAX_MEMORY_LIMIT', 'nilai-terukur-untuk-admin' );

Jangan memakai nilai contoh dari internet sebagai angka final. Periksa phpinfo() hanya pada lingkungan terlindung atau gunakan CLI yang benar. Cocokkan loaded configuration file, ukur peak memory proses, lalu bedakan kebutuhan frontend, wp-admin, impor, pemrosesan gambar, dan cron.

Aktifkan OPcache PHP WordPress 8.3

OPcache menyimpan bytecode yang telah PHP kompilasi di shared memory. Jadi PHP tidak perlu memuat dan mengurai file yang sama pada setiap request. Pantau opcache.enable, opcache.memory_consumption, opcache.interned_strings_buffer, opcache.max_accelerated_files, opcache.validate_timestamps, dan opcache.revalidate_freq.

Jangan memilih opcache.memory_consumption hanya dari total RAM VPS. Gunakan opcache_get_status() melalui mekanisme admin yang aman. Lihat used/free/wasted memory, jumlah script, hit rate, cache full, dan restart; hapus endpoint observasi setelah selesai.

Bila opcache.validate_timestamps=0, PHP tidak melihat perubahan file sampai operator mereset cache atau memuat ulang service terkait. Mode itu menuntut proses deploy dengan invalidasi sengaja. opcache.revalidate_freq tidak berlaku ketika pemeriksaan timestamp mati.

Realpath Cache Bukan Prioritas Pertama

realpath_cache_size menyimpan path yang telah PHP selesaikan, sementara realpath_cache_ttl mengatur masa simpannya. Aplikasi PHP dengan banyak file dapat memperoleh manfaat. Namun ukur setelah PHP-FPM dan OPcache stabil; manual PHP mencatat bahwa open_basedir menonaktifkan realpath cache.

Terapkan PHP 8.3 di aaPanel

Buka aaPanel → App Store → PHP 8.3. Pada antarmuka tersebut, dokumentasi aaPanel menempatkan Service, Install extensions, Configuration, upload limit, timeout limit, Configuration file atau php.ini, serta FPM profile; nama tab dapat sedikit berubah mengikuti rilis panel.

Utamakan GUI bagi operator yang belum terbiasa mengedit file pool. Setelah menyimpan satu kelompok perubahan, jalankan config test dan muat ulang PHP-FPM. Periksa status, buka situs, uji wp-admin, dan baca log sebelum meneruskan ke kelompok berikutnya.

/etc/init.d/php-fpm-83 configtest
/etc/init.d/php-fpm-83 status
/etc/init.d/php-fpm-83 reload
/etc/init.d/php-fpm-83 restart

Dokumentasi service aaPanel menempatkan program PHP 8.3 di /www/server/php/83/. Direktori /www/server/php/83/etc/ memuat konfigurasi utamanya. Pakai reload untuk pemuatan mulus; gunakan restart saat perlu dan siapkan rencana pemulihan.

Sebelum mengubah web server, aaPanel menyarankan backup konfigurasi situs dan pemeriksaan akses setelah perpindahan. Perbandingan dedicated server dan VPS memberi konteks resource saat Anda menilai kelas mesin. Namun keputusan tuning tetap harus berasal dari pengukuran server ini.

Baseline Menurut Kelas VPS

Kelas VPS membantu menetapkan sikap awal, bukan angka worker. Tabel berikut sengaja tidak memberi nilai pm.max_children karena angka itu harus dihitung dari budget PHP-FPM dan RSS worker milik workload Anda.

Swap berfungsi sebagai bantalan darurat, bukan tambahan RAM untuk melayani request aktif. Ketika benchmark memakai swap, latency sering menjadi tidak stabil. Turunkan concurrency atau worker, cari proses yang membesar, dan pulihkan cadangan memori.

Contoh Struktur Konfigurasi FPM

pm = dynamic
pm.max_children = [hasil-perhitungan-dan-uji]
pm.start_servers = [hasil-uji-start]
pm.min_spare_servers = [hasil-uji-spare-minimum]
pm.max_spare_servers = [hasil-uji-spare-maksimum]
pm.max_requests = [hasil-pengamatan-rss-worker]

Ini contoh struktur, bukan angka universal. Isi setiap nilai dari hasil benchmark server dan workload WordPress Anda. Lalu ubah satu kelompok parameter per putaran agar Anda tetap dapat menelusuri penyebab perubahan metrik.

CPU:
RAM:
Storage:
Swap:

RAM OS dan service panel:
RAM Nginx dan Apache:
RAM MariaDB:
RAM Redis:
Cadangan:
Budget PHP-FPM:

RSS worker rata-rata:
RSS worker pada request berat:
Batas teoretis pm.max_children:

CPU saat load test:
TTFB:
RPS:
p95 latency:
Error:
Swap:

Benchmark Ulang dan Putuskan Hasil

Gunakan endpoint, data, cache state, durasi, concurrency, waktu pengujian, dan tool yang sama dengan baseline. Benchmark yang berubah metodenya tidak dapat menjawab apakah konfigurasi baru benar-benar menghasilkan perbaikan.

Pertahankan konfigurasi ketika latency turun atau stabil dan throughput naik pada workload yang sama. Error harus tetap nol, swap tidak tertekan, serta service lain masih mempunyai ruang. Kenaikan RPS kecil dengan lonjakan besar RAM dan p95 lebih buruk bukan kemenangan.

Setelah itu, dokumentasikan perubahan, waktu, metrik, dan cara rollback. Data tersebut membuat putaran fine-tuning berikutnya dapat dibandingkan, sedangkan angka tanpa konteks hanya menjadi catatan yang sulit dipakai ulang.

Diagnosis Ketika WordPress Tetap Lambat

Jika max children reached naik, listen queue muncul, latency memburuk saat concurrency bertambah, sedangkan CPU dan RAM masih longgar, pm.max_children mungkin terlalu kecil. Namun periksa slow log lebih dulu karena satu request lambat dapat menahan worker dan menciptakan gejala yang sama.

Bila RAM habis, swap bertambah, CPU terus penuh, atau koneksi database menumpuk, batas tersebut terlalu besar. OOM kill setelah penambahan worker memperkuat diagnosis itu. Turunkan nilai, pulihkan cadangan resource, lalu cari hambatan aplikasi dan database.

1. Periksa CPU, RAM, swap, load, dan storage latency.
2. Periksa worker aktif, listen queue, dan batas child.
3. Baca slow log serta error log PHP-FPM.
4. Telusuri query database, plugin, tema, dan autoload.
5. Periksa WP-Cron, background job, serta API luar.
6. Pertimbangkan upgrade setelah bottleneck terukur.

Redis dapat mengurangi sebagian kerja database melalui object cache, tetapi request dinamis tetap memerlukan worker PHP. Full-page cache dapat melewati PHP untuk request tertentu, sementara OPcache mengurangi kompilasi script; ketiganya menyelesaikan lapisan masalah yang berbeda.

Nginx-only, CyberPanel, dan Panel Lain

Nginx-only dapat mengurangi jumlah service dan cocok bagi operator yang memahami konfigurasi Nginx. Namun Nginx tidak memproses .htaccess; rewrite, header, dan aturan akses Apache perlu diterjemahkan, jadi mode ini tidak otomatis lebih cepat pada setiap workload.

CyberPanel memakai OpenLiteSpeed dan LSPHP, bukan pool PHP-FPM aaPanel. Prinsip capacity planning tetap sama: ukur RAM worker, concurrency, CPU, database, lalu jalankan benchmark. Namun parameternya memakai Max Connections dan PHP_LSAPI_CHILDREN, bukan pm.max_children.

Panel lain pun perlu pemeriksaan handler, lokasi php.ini, file process manager, service command, dan log miliknya. Jangan menyalin path aaPanel ke CWP, cPanel/WHM, atau sistem custom tanpa memeriksa dokumentasi rilis yang terpasang.

FAQ Setting PHP aaPanel WordPress VPS

Berapa memory_limit WordPress yang ideal?

Tidak ada satu angka ideal untuk semua situs. Pilih limit dari peak memory request yang sah dan beri cadangan terukur. Lalu cek agar concurrency terburuk tidak menghabiskan budget PHP-FPM atau resource service lain.

Berapa pm.max_children untuk RAM 2 GB?

RAM total belum cukup untuk menjawabnya. Kurangi konsumsi OS, panel, web server, database, cache, proses latar, dan cadangan. Bagi budget PHP-FPM dengan RSS worker pada workload nyata, lalu uji lagi terhadap CPU serta latency.

Apakah worker lebih banyak selalu membuat WordPress cepat?

Tidak. Worker tambahan membantu saat request menunggu dan resource masih longgar. Namun jumlah berlebih dapat memenuhi RAM, menekan CPU, menambah koneksi database, serta memperburuk antrean.

Apakah OPcache perlu di production?

OPcache lazim dipakai pada PHP production karena menyimpan bytecode hasil kompilasi. Aktifkan melalui aaPanel, lalu ukur pemakaian memory, jumlah script, hit rate, dan wasted memory. Periksa pula cache full serta perilaku deploy sebelum mengubah ukurannya.

Apakah VPS 1 GB cukup untuk WordPress?

VPS 1 GB dapat menjalankan situs ringan dengan cache dan konfigurasi konservatif. Namun stack Nginx + Apache + database + Redis + PHP memiliki ruang kecil. Pantau available memory dan swap; hilangkan service yang tidak perlu atau pilih stack lebih sederhana bila cadangan terus menipis.

Apakah benchmark boleh dilakukan di production?

Observasi ringan dapat berjalan dengan pengawasan, tetapi load test yang menaikkan concurrency lebih aman di staging atau waktu traffic rendah. Tetapkan batas penghentian, pantau error dan resource, serta jangan menguji domain yang bukan milik Anda.

Verifikasi Akhir Sebelum Menyimpan Konfigurasi

Konfigurasi PHP terbaik bukan angka terbesar. Pilih kombinasi yang melayani workload WordPress dengan latency rendah dan error terkendali, tanpa tekanan swap atau perebutan resource. Simpan perubahan setelah config test lulus, Anda bisa mengakses situs dan wp-admin, log bersih, serta benchmark ulang memakai skenario yang sama.

Jika hasilnya memburuk, rollback kelompok perubahan terakhir dan bandingkan kembali. Siklus ukur → ubah → verifikasi memberikan bukti yang dapat dipakai, sedangkan satu konfigurasi hasil salin-tempel hanya memindahkan tebakan ke server produksi.