Panel server yang dibangun untuk satu pekerjaan — menjalankan 6amMart
Anda menyewa server segar, jalankan satu perintah, dan dapatkan halaman web yang menjalankan toko Anda. SixPanel memasang web server, database, PHP, cache, background worker, scheduler, server websocket dan HTTPS — semua dikonfigurasi seperti yang benar-benar dibutuhkan 6amMart.
Semuanya berjalan di server Anda. Database, gambar, data pelanggan Anda.
- Lebih cepat daripada aaPanel yang sudah distel sempurna — hardware sama, toko sama, terukur
1.76×
Lebih cepat daripada aaPanel yang sudah distel sempurna — hardware sama, toko sama, terukur
- Menjalankan satu toko lengkap
2 core / 4 GB
Menjalankan satu toko lengkap
- Dipublikasikan di CodeCanyon, setup awal untuk Anda
Gratis
Dipublikasikan di CodeCanyon, setup awal untuk Anda
- Bahasa antarmuka panel
8
Bahasa antarmuka panel
Membaca halaman ini dengan asisten AI?
Mendapatkan SixPanel
SixPanel dipasang dengan satu perintah. Tidak ada yang perlu didaftarkan, tidak ada kunci yang dimasukkan, tidak ada kode yang ditempel — perintahnya sama untuk semua orang. Ini gratis.
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bashYang melindungi sebuah perintah yang berjalan sebagai root bukan alamatnya — melainkan tanda tangan rilisnya. Pemasang membawa kunci penanda tangan kami dan otomatis menolak berkas apa pun yang tidak cocok. Halaman pemasangan menjelaskannya.
Coba dulu sebelum mengunduh
Login hanya-baca
Username: demo Password: g5b7h878vjQN
Read-only: every change is refused and secrets are masked.
The shop runs a real dataset — tens of thousands of orders — so the screens behave the way they will on yours, not the way a demo with forty products does. Two things are switched off on the demo: maps and SMS one-time passwords. Both use keys locked to a single server, which is how they should be held, so they cannot answer from a demo host. They work normally on your own install.
Dapatkan SixPanel
Free- Pembaruan termasuk — setiap rilis masuk ke CodeCanyon tanpa biaya tambahan, dan panel juga bisa memperbarui dirinya sendiri. Tanpa server lisensi, tanpa kunci yang perlu diperpanjang.
- Penyiapan pertama gratis — kirim kode pembelian dan detail server Anda lewat WhatsApp atau email.
Tidak ada yang perlu diaktifkan — berjalan di server Anda sendiri, tidak menghubungi siapa pun, dan tetap bekerja meski situs ini sedang mati.
Apa ini, dan apa yang digantikannya
Script-nya milik Anda. Tetap ada yang harus menjalankan servernya.
Anda membeli script 6amMart dari CodeCanyon. Isinya sebuah folder berisi file. Sebelum bisa menerima pesanan, ada yang harus memasang web server, database, PHP, cache, worker latar belakang, dan sertifikat HTTPS — lalu menjaga semuanya tetap berjalan.
SixPanel adalah bagian yang melakukan itu. Anda menyewa server baru, menjalankan satu perintah, dan mendapat panel kontrol berbasis web. Dari panel itu Anda menyambungkan domain, mendapat HTTPS gratis, memasang kode 6amMart Anda dari git, memperbaruinya, mencadangkannya, dan melihat apa yang rusak saat ada yang rusak.
Semuanya berjalan di server Anda. Database Anda, gambar Anda, data pelanggan Anda.
Tiga cara mengendalikannya
Panelnya
Di browser. Di sinilah Anda melakukan hampir semuanya.
Perintah sixpanel
Di server, untuk saat panelnya tidak mau terbuka.
Installer
Yang Anda jalankan sekali.
Dengan ini versus tanpa ini
Setiap baris adalah pekerjaan yang sama, dikerjakan dengan dua cara. Kiri adalah apa yang dituntut menjalankan 6amMart tanpa SixPanel; kanan adalah jadinya dengan SixPanel.
Mendapatkan server berjalan
Tanpa ini
Membangun server dengan tangan — nginx, PHP-FPM, MariaDB, Redis, certbot, cron, process supervisor — dan menjaga semuanya tetap hidup
Dengan SixPanel
Satu perintah install. systemd adalah supervisor — restart saat crash, restart saat reboot, batasan memori, rotasi log dan health check pada setiap service, dideklarasikan di satu tempat. Pada runtime Docker, Docker Compose melakukan pekerjaan yang sama.
Mengukur database dan PHP
Tanpa ini
Menebak pengaturan database dan PHP, atau membayar seseorang untuk mengurutkannya
Dengan SixPanel
Autotune membaca mesin asli dan menulis ukuran: PHP worker, database buffer pool, cache memory, temporary table, sort dan join buffer dan redo log. Mencakup 1 core / 2 GB hingga 16 core / 32 GB, dan dua tempat yang menghitung angka-angka itu diperiksa satu sama lain pada setiap build — karena pernah tidak setuju pada 66 dari 432 nilai.
Shipping a change to the shop
Tanpa ini
Paying a developer for every deployment
Dengan SixPanel
Push ke git, toko ikut terbarui. Riwayat deploy dan rollback, dengan 30 deploy terakhir disimpan.
Knowing the backup works
Tanpa ini
Hoping the backup works
Dengan SixPanel
Pencadangan berjalan sesuai jadwal dengan masa simpan, dan sekali seminggu panel memuat cadangan terbaru ke basis data sekali pakai, menghitung isinya, lalu menghapusnya lagi.
When the shop goes down
Tanpa ini
Membaca jejak galat untuk mencari tahu kenapa toko mati
Dengan SixPanel
Halaman Health berisi sekitar dua puluh pemeriksaan, masing-masing dengan satu kalimat lugas soal akibatnya dan tepat satu tombol perbaikan.
What it costs
Tanpa ini
Membangun dan merawat tumpukan itu sendiri adalah biayanya, entah Anda bayar dengan jam kerja atau dengan tagihan.
Dengan SixPanel
Tidak ada. SixPanel gratis di CodeCanyon, pemasangan dan penyiapan pertama gratis, dan perintah pemasangannya sama untuk semua orang — tidak ada kunci yang dimasukkan, tidak ada kode yang ditempel. Pembaruan datang lewat CodeCanyon, dan panel juga bisa memperbarui dirinya sendiri di tempat.
Apa yang tidak digantikannya
Ini tidak menjual script 6amMart kepada Anda.
Itu Anda beli dari CodeCanyon, dan SixPanel memasang kode yang sudah Anda miliki.
Ini bukan shared hosting.
Tidak ada akun cPanel, tidak ada situs lain di mesin itu. SixPanel memakai seluruh server.
Ini tidak menjalankan toko Anda.
Harga, produk, kurir, dan pesanan ada di panel admin 6amMart sendiri.
Ini bukan CDN dan bukan layanan anti-DDoS.
Cloudflare-lah lapisan edge yang sebenarnya, dan dokumentasinya menyebutkan itu.
Dua cara menjalankannya
Satu panel, dua runtime — dan salah satunya adalah rekomendasi
Keduanya adalah produk yang sama dengan panel yang sama, perintah yang sama dan manual yang sama. Mereka hanya berbeda dalam cara perangkat lunak yang mendasar diinstal, dan perbedaan itu terukur.
- Direkomendasikan
SixPanel
Berjalan langsung di server
nginx, PHP-FPM, MariaDB, dan Redis dipasang dari arsip distribusi rilis itu sendiri dan diawasi oleh systemd. Tidak ada yang dikontainerkan, jadi setiap hop adalah unix socket dan basis data disetel untuk mesinnya, bukan untuk sebuah container. Ini yang lebih cepat dari keduanya, dan ke sinilah semua pekerjaan baru mengalir.
Perintah instalasi
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bash- Sistem operasi
- Ubuntu 26.04 LTS (direkomendasikan), Ubuntu 24.04 LTS, atau Debian 13
- PHP
- 8.5 di Ubuntu 26.04, 8.4 di Debian 13, 8.3 di Ubuntu 24.04 — selalu paket milik rilis itu sendiri
- Basis data
- MariaDB 11.8 di Ubuntu 26.04 dan Debian 13, 10.11 di Ubuntu 24.04 — dari arsip yang sama
- Diawasi oleh
- systemd
SixPanel Docker
Berjalan dalam container
Stack yang sama sebagai layanan Docker Compose. Keunggulannya adalah versi PHP dan basis data sama sekali tidak bergantung pada host: image-nya dipatok pada PHP 8.4 dan MariaDB 10.11, di rilis mana pun Anda menjalankannya. Ia masih memasang, dan server yang sudah menjalankannya tetap menerima pembaruan.
Perintah instalasi
curl -fsSL https://installer.allsweb.net/sixpanel-docker/install.sh | sudo bash- Sistem operasi
- Ubuntu 24.04 / 26.04 LTS, Debian 13 — dan Debian 12, yang memang terpasang tetapi tidak direkomendasikan
- PHP
- 8.4, di dalam container
- Basis data
- MariaDB 10.11, di dalam container
- Diawasi oleh
- Docker Compose
Yang mana yang harus Anda pilih?
Pilih SixPanel kecuali ada yang secara khusus memerlukan yang lain. Ini lebih cepat di setiap endpoint yang diukur, ia mengisolasi proyek di kernel daripada di dalam PHP, dan ini adalah runtime yang terus berkembang.
Pilih SixPanel Docker kalau Anda ingin seluruh stack terisolasi di dalam container, atau kalau Anda memang butuh MariaDB 10.11 di rilis yang arsipnya tidak membawanya — image-nya dipatok pada PHP 8.4 dan MariaDB 10.11 terlepas dari host. Ia juga masih terpasang di Debian 12, tetapi jangan memulai toko baru di sana: dukungan keamanan Debian 12 berakhir pada Juli 2026, dan kernel, glibc, Docker, serta OpenSSH tetap datang dari arsip host.
Jelas tentang hal itu: pengembangan baru masuk ke runtime native. SixPanel Docker dipertahankan, tidak diperluas. Jika Anda memasang hari ini dan memiliki pilihan bebas sistem operasi, pilih yang native.
Diukur, bukan diklaim
Tiga server, toko yang sama, satu perbedaan
Setiap angka kinerja di halaman ini berasal dari satu putaran pengukuran di server nyata menjalankan data toko nyata. Pengaturan, metode dan skrip dipublikasikan, begitu juga bagian yang masih belum dijelaskan.
1.76×
lebih cepat daripada aaPanel yang fully tuned
1,82× ketika empat permintaan tiba sekaligus. Diukur di seluruh endpoint yang mencapai PHP di kedua server.
Cara diukur
- Tiga server
- AMD EPYC 7713, 2 vCPU, 4 GB, Ubuntu 24.04 — identik kecuali untuk panel yang diuji
- Aplikasi yang sama
- Kode 6amMart yang sama di ketiga server, diverifikasi byte untuk byte: lockfile dependency identik, hash identik di seluruh aplikasi, rute, modul dan konfigurasi
- Toko yang sama
- 66.701 pesanan · 3.865 item · 85 toko · 17.534 pelanggan — satu dataset nyata, disalin baris per baris
- Metodenya
- Setiap box mengukur dirinya sendiri melalui loopback dengan hostname asli dan sertifikatnya. 40 sampel per sel setelah warm-up yang dibuang, dan setiap angka yang dilaporkan adalah median dari pass berpasangan yang bergantian.
- Tidak ada yang dibuang dengan diam-diam
- Nol respons rate-limited dan nol kesalahan di setiap baris yang dipublikasikan. Permintaan yang diblokir atau gagal menjawab sangat cepat, jadi run yang menyembunyikannya melaporkan angka yang lebih baik dari yang sebenarnya.
Setiap endpoint, semua empat konfigurasi
Median milidetik — satu permintaan / empat sekaligus. Lebih rendah adalah lebih baik.
| Endpoint | SixPanel | SixPanel Docker | aaPanel, stok | aaPanel, tuned |
|---|---|---|---|---|
/api/v1/categoriesDipaksa ke PHP di ketiga server — baris like-for-like yang paling bersih | 29.146.9 | 34.570.9 | 52.0103.6 | 56.199.9 |
/api/v1/stores/get-stores/allDaftar toko yang dilihat setiap pelanggan pertama kali | 17.933.3 | 24.545.0 | 37.876.4 | 38.084.2 |
/api/v1/items/searchPembacaan terberat di aplikasi | 18.035.9 | 25.143.2 | 44.368.3 | 40.971.1 |
/api/v1/items/popularBergabung di seluruh katalog | 41.677.2 | 50.794.6 | 58.4112.1 | 65.3122.9 |
/api/v1/customer/order/listMasuk dan tidak dapat dicache — panggilan paling lambat di setiap box | 102.1191.8 | 123.3242.3 | 139.6245.8 | 152.7288.9 |
/ (admin entry)SixPanel mengalihkan dalam 430 byte; aaPanel merender 352 KBPekerjaan berbeda | 59.6102.7 | 63.5156.3 | 76.7144.5 | 84.8171.2 |
storefront homeSixPanel merender halaman; yang aaPanel adalah cache-hit proxyPekerjaan berbeda | 54.3104.0 | 111.4213.5 | 83.0— | —— |
websocket handshakeWaktu untuk koneksi diterima | 2.35.8 | 4.211.6 | 2.66.3 | —— |
Hijau adalah konfigurasi tercepat di baris itu.
Dua baris ditandai karena server tidak melakukan pekerjaan yang sama di dalamnya. Angka-angkanya nyata; mereka hanya bukan perlombaan yang adil, dan ditampilkan daripada dijatuhkan.
Kemudian rival fully tuned, dan gap tidak tertutup
Mengalahkan pesaing pada pengaturan defaultnya tidak membuktikan apa pun. Jadi box aaPanel disesuaikan dengan cara administrator yang kompeten akan menyesuaikannya, dan setiap angka diambil lagi.
- PHP opcache dinaikkan dari 128 MB menjadi 256 MB, dengan validasi timestamp dimatikan
- Buffer pool basis data dinaikkan dari 256 MB menjadi 1.152 MB — empat setengah kali lebih besar
- File log basis data dinaikkan dari 128 MB menjadi 320 MB, dan query cache dimatikan
- Worker PHP dikoreksi dari over-committed 50 turun ke sized 14
- Cache path dikuadrupkan dan buffer server web digandakan
PHP 8.4 dan compiler JIT-nya sengaja dibiarkan dihidupkan. Itu adalah keuntungannya, dan menghilangkannya akan menggagalkan tes.
Terhadap box stok SixPanel adalah 1,65× / 1,80× lebih cepat. Terhadap box fully tuned ini adalah 1,76× / 1,82×. Gap bergeser sedikit ke arah lain.
Battery basis data tidak bergerak sama sekali. Buffer pool empat setengah kali lebih besar mengubah tidak ada, karena laporan ini adalah pekerjaan processor-bound atas baris yang sudah dalam memori. Internalsnya memang meningkat — cache hit rate 99,856% menjadi 99,930%, temporary tables spilling ke disk 47,3% turun menjadi 22,1% — dan waktu respons tidak mengikutinya.
Di mana gap sebenarnya berasal
Klaim kecepatan sangat sedikit bernilai tanpa penyebab. Jadi perbedaannya dipecah di lima endpoint yang mencapai PHP di kedua box, satu variabel pada satu waktu.
| Konfigurasi | Satu permintaan | Empat sekaligus |
|---|---|---|
| Seperti dua box dikirim | 1.99× | 1.91× |
| Setelah mematikan pembatasan direktori aaPanel | 1.32× | 1.29× |
| Setelah juga mengoreksi mode compiler JIT-nya | ≈1.25× | ≈1.21× |
Gap, diatribusikan
- Pembatasan direktori PHP60%
- Mode compiler JIT yang salah8%
- Versi PHP0%
- Masih belum dijelaskan32%
Tentang sepertiga dari perbedaannya tidak terhitung, dan dipublikasikan sebagai belum dijelaskan daripada dikreditkan kepada kami. Kandidat untested terkemuka adalah bahwa aaPanel mengompilasi PHP sendiri sementara Ubuntu mengirimkan paket. Tidak ada yang tidak bisa diisolasi pada satu mesin, jadi tidak ada yang diklaim.
Bentuknya lebih penting daripada rasionya
Pajaknya adalah biaya tetap per permintaan, jadi mendominasi pekerjaan pendek dan menghilang pada pekerjaan panjang. Laporan admin 20,9 detik yang sama hanya 1,17× terpisah antara dua box. Jika toko Anda sebagian besar laporan berat, perbedaannya akan kecil. Jika sebagian besar panggilan API aplikasi telepon — yang merupakan sebagian besar toko pengiriman makanan — itu adalah seluruh perbedaan.
Cara kerjanya, secara lengkap
Penyebab tunggal terbesar adalah satu pengaturan PHP, dan mengorbankan 16 hingga 26 ms di setiap permintaan≈60% dari gap
aaPanel membatasi direktori mana yang dapat disentuh PHP. Itu adalah fitur keamanan nyata, jadi ia berhak atas pengukuran nyata daripada ditulis sebagai bloat.
Tiga pasangan bergantian, dengan arm "off" menulis file pengaturan kosong sehingga pemindaian per-direktori masih terjadi di kedua arm — jika tidak, perbandingan akan mengukur pemindaian daripada pengaturan.
Setiap endpoint bergerak antara 17% dan 46%. File statis, yang tidak pernah mencapai PHP sama sekali, tidak bergerak — itu adalah kontrol, dan itulah yang membuat sisanya hasil daripada kebetulan. Spread arm-to-arm di box ini adalah 1% hingga 13%.
Mekanisme kemudian dihitung tiga cara terpisah: 5.862 filesystem lookups per permintaan dengan pembatasan on, 214 dengan itu off, dan 217 di SixPanel. Dengan itu on, 400 path resolutions menambahkan nol entri ke path cache PHP; dengan itu off mereka menambahkan 509. Cache hanya dinonaktifkan, itulah mengapa pengaturan ukuran cache tuned aaPanel sendiri tidak membelinya apa pun.
Dikonfirmasi di mesin kedua dalam arah lain: menghidupkan pembatasan yang sama untuk SixPanel mereproduksi 17 hingga 23 ms waktu ekstra per permintaan.
Layak diketahui jika Anda mengadministrasi server: pengaturan ini ada di file per-direktori yang empat tempat lain tidak menunjukkan. Membaca nilai kembali dari proses yang sebenarnya melayani permintaan adalah satu-satunya check yang dapat diandalkan.
| Endpoint | Pembatasan on | Pembatasan off | Ubah |
|---|---|---|---|
/api/v1/config | 37.7 | 20.3 | −46% |
/api/v1/stores/get-stores/all | 39.8 | 23.5 | −41% |
/api/v1/items/search | 40.6 | 24.1 | −41% |
/api/v1/categories | 55.4 | 33.7 | −39% |
/api/v1/items/popular | 70.7 | 51.5 | −27% |
/ (admin entry) | 85.7 | 66.4 | −23% |
/api/v1/customer/order/list | 154.9 | 128.9 | −17% |
static assetKontrol — tidak pernah mencapai PHP | 0.4 | 0.4 | 0% |
aaPanel menjalankan mode compiler JIT yang salah untuk aplikasi ini≈8% dari gap
Pengaturan JIT PHP adalah angka empat digit, bukan switch on/off, dan dua mode bernama berbeda: "function" adalah 1205 dan "tracing" adalah 1254. Skrip tuning yang hanya memeriksa apakah JIT diaktifkan akan dengan senang hati meninggalkan yang salah di tempat dan melaporkan pekerjaan seperti dilakukan.
aaPanel mengirim 1205. SixPanel mengirim tracing. Tiga pasangan bergantian menempatkan tracing di depan di 9 dari 9 endpoints di satu permintaan dan 9 dari 9 di empat sekaligus — geometric mean 5,1% dan 6,2%.
Satu perbedaan pun dari itu duduk di dalam noise mesin ini. Delapan belas dari delapan belas jatuh sama tidak.
Untuk 6amMart khususnya, tracing adalah mode yang tepat: function JIT menargetkan loop numerik ketat, yang permintaan Laravel tidak menjalankan.
Menjadi satu versi PHP di belakang tidak mengorbankan apa pun — diukur, bukan diasumsikan0% dari gap
SixPanel memasang PHP mana pun yang dibawa arsip rilis itu sendiri — 8.5 di Ubuntu 26.04, 8.4 di Debian 13, 8.3 di Ubuntu 24.04 — karena tetap memakai paket milik distribusi berarti pembaruan keamanan datang otomatis tanpa repositori pihak ketiga di jalur yang melayani. Bantahan yang jelas adalah bahwa PHP yang lebih baru lebih cepat.
Box aaPanel memiliki kedua versi diinstal, jadi ia bisa menjawab ini dengan bersih. Pool 8.3 pertama kali diberikan seluruh tuning 8.4 — ia telah ditinggalkan pada default, yang akan menggagalkan hasilnya — dan pengaturan diverifikasi dari proses yang sedang berjalan daripada dari file.
Tiga pasangan bergantian: geometric mean 8.3 terhadap 8.4 adalah 0,9994. 8.3 berada di depan di 3 baris dari 7, dan setiap perbedaan lebih kecil dari setidaknya spread run-to-run satu arm sendiri. Laporan admin lambat setuju.
Jadi aturan yang menjaga SixPanel pada paket milik distribusi itu gratis — tidak mengorbankan kecepatan. Tidak ada pula plafon yang perlu dihindari: composer.json 6amMart mendeklarasikan batas di bawah 8.5, tetapi itu deklarasi dan bukan pengukuran, dan menjalankan kodenya di 8.5.4 menghasilkan ekspor spreadsheet yang identik byte demi byte serta Laravel yang boot, baik pada pohon CodeCanyon murni maupun pada fork kami sendiri.
Apa yang diperiksa dan ditemukan bukan penyebabnyaEnam kandidat
Masing-masing adalah penjelasan plausibel yang bisa diajukan seseorang. Masing-masing diukur dan disingkirkan.
- Server web
- Setiap endpoint diberi waktu melalui kawat dan lagi di dalam satu proses PHP, di kedua box. Perbedaannya adalah 0 hingga 7 ms di aaPanel dan 3,5 hingga 5 ms di SixPanel, sebagian besar jabat tangan enkripsi. Milik aaPanel tidak lebih besar, meskipun menulis entri log akses per permintaan.
- Basis data
- Waktu query secara efektif identik di semua tiga konfigurasi. Datasets dalam sekitar 1% di setiap tabel, dan konfigurasi cocok setelah tuning selain dari patch level.
- Bagaimana PHP mencapai basis data
- Keduanya di socket lokal, diverifikasi dari proses yang sedang berjalan daripada dari file konfigurasi.
- Layer cache
- Dihitung daripada dibaca dari file konfigurasi: 17,1 perintah cache per permintaan di aaPanel, 18,1 di SixPanel. Tidak ada yang jatuh diam-diam kembali ke disk.
- Cache kode yang dikompilasi PHP
- Nol out-of-memory events, nol hash collisions dan nol restarts manual di keduanya. SixPanel pada hit rate 99,86% dengan 0% terbuang.
- Hardware
- Identik hingga model prosesor dan set mitigasi keamanan yang diaktifkan.
Hal paling lambat di 6amMart bukan server, dan tidak ada panel yang bisa memperbaikinyaKode aplikasi
Semua 297 halaman admin diberi waktu di dataset nyata 66.701-pesanan. 290 dari mereka menjawab dalam waktu kurang dari 300 ms. Panel tidak secara luas lambat.
Tujuh halaman menyebabkan seluruh masalah. Yang terburuk, laporan transaksi hari-demi-hari, memakan waktu 20,86 detik, dari mana 12,43 detik dihabiskan di dalam driver basis data — dan satu pertanyaan tunggal berjalan 122 kali pada 87,6 ms masing-masing, yaitu 10,7 detik sendiri.
Itu hadir di setiap server yang diuji dan tidak tersentuh oleh setiap pengaturan yang dicoba, termasuk pass tuning aaPanel penuh: 20.925 ms sebelumnya, 20.470 ms sesudahnya.
Ini adalah kode 6amMart sendiri, jadi tidak ada control panel yang bisa memperbaikinya dan tidak ada yang harus mengklaim. Itu ditulis lengkap melawan aplikasi itu sendiri, dan itu adalah jenis hal yang layanan instalasi 6amMart kami ada untuk mengatasi.
Semua yang kami terbitkan
Semua laporan, di satu tempat
Tidak ada angka di halaman ini yang berdiri sendiri — masing-masing berasal dari laporan yang diterbitkan lengkap dengan metodenya, catatannya, dan hasil-hasil yang tidak menyanjung kami. Bacalah sebelum Anda membeli; memang untuk itulah laporan-laporan ini dibuat.
SixPanel vs aaPanel
1.76× lebih cepat pada satu request, 1.82× pada empat yang datang bersamaan — melawan aaPanel yang sudah di-tuning penuh, dengan penyebabnya diurai dan 32% dari selisihnya secara jujur diberi label belum terjelaskan.
SixPanel vs SixPanel Docker vs aaPanel
Tiga panel di hardware identik dan toko yang identik hingga ke byte — metode lengkap di balik angka-angka utamanya.
SixPanel vs CloudPanel
Yang satu ini imbang: CloudPanel adalah software serba guna yang bagus. Pertanyaannya, masalah mana yang sedang Anda selesaikan.
SixPanel vs server polos
Apa yang ditambahkan panel dibanding server rakitan tangan yang jadi titik awal kebanyakan pemilik toko — dan berapa harganya dalam setahun.
Sistem operasi yang mana
Ubuntu 26.04 vs Ubuntu 24.04 vs Debian 13, diukur: kecepatannya seri, jendela dukungannya tidak.
Engine database yang mana
Lima mesin melawan toko nyata. MariaDB 11.8 dan 10.11 seri pada seluruh aplikasi; kedua MySQL tidak bisa menjalankannya tanpa modifikasi.
6amMart teroptimasi — hasil yang terukur
Strip featured yang 22× lebih cepat, penyisiran 297 halaman admin, laporan 17.5 detik yang dibawa ke 0.7 — beserta dua halaman yang sengaja dibiarkan lambat, diterbitkan berdampingan dengan kemenangannya.
Uji skala
66,701 pesanan nyata, 113,231 baris pesanan — dataset tempat cacat-cacat senyap itu muncul ke permukaan.
Cacat yang diperbaiki
Yang menguras uang tanpa pernah menampilkan error — kupon, jam, stok, pembayaran ganda.
Yang masih terbuka
Halaman yang membuat empat lainnya layak dibaca: apa yang belum kami selesaikan, dinyatakan apa adanya.
Changelog
Setiap rilis, termasuk kesalahan-kesalahannya dan apa yang kami pelajari darinya.
Apa yang benar-benar Anda dapat
Dikelompokkan sesuai cara pembeli memikirkan pekerjaannya
Dua hal membawa catatan khusus. Pemindahan dari server lama dan pemulihan di mesin yang sama hanya diverifikasi lewat pembacaan kode pada putaran 15 Agustus dan tidak dijalankan. Keduanya ditandai di bawah. Selebihnya sudah dicoba atau merupakan permukaan yang dikirim dan bisa diperiksa — tetapi bentuk kalimat yang jujur adalah “ini ikut dikirim”, bukan “ini sudah terbukti di server jenis Anda”.
Membuatnya berjalan
Dari server sewaan sampai login panel, tanpa merakit stack sendiri.
- Satu perintah. Perintah instalasi diunduh, dicocokkan dengan sidik jari yang dipublikasikan, dan baru setelah itu dijalankan. Kalau sidik jarinya tidak cocok, perintah berhenti dan tidak ada yang dipasang.
- Ia menolak server yang tidak bisa dijalankannya, dengan menyebut alasannya, sebelum mengunduh apa pun: sistem operasi salah, jenis prosesor salah, memori terlalu kecil, ada panel kontrol lain, atau ada yang sudah memakai port 80 atau 443.
- Wizard penyiapan saat login pertama: dasar → sandi → domain → SSL → aplikasi → cadangan.
- Autotune saat instalasi, dan sesuai permintaan sesudahnya. Ia menentukan ukuran database, cache, dan worker PHP dari mesin sebenarnya.
- Menjalankan satu toko penuh pada 2 core dan 4 GB.
- Diverifikasi lewat pembacaan kode, tidak dijalankan: Atau pindahkan toko yang sudah ada. SixPanel bisa menarik instalasi live dari server lama lewat SSH — file pengaturan, file unggahan, dan dump database yang dialirkan menyeberang. Tidak dicoba pada putaran 15 Agustus, hanya diverifikasi lewat pembacaan kode. Jalankan pada server cadangan sebelum Anda mengandalkannya, dan simpan mesin lama sampai Anda melakukannya.
Kenapa penting: hari pertama adalah tempat kebanyakan toko kehilangan satu minggu — yang ini berakhir dengan halaman yang berfungsi.
Domain dan HTTPS Anda
Sertifikat asli, diperbarui untuk Anda, dan Cloudflare ditangani dengan benar.
- Sertifikat Let's Encrypt gratis, diperbarui otomatis oleh tugas harian.
- Lebih dari satu domain per toko, per target (admin, storefront, websocket), masing-masing dengan flag primary, SSL, dan Cloudflare-nya sendiri.
- Sadar Cloudflare. Ia lebih dulu mencoba sertifikat Let's Encrypt asli lewat proxy Cloudflare, yang berfungsi dengan mode Full (strict). Kalau itu tidak bisa dilakukan, ia mundur ke sertifikat origin self-signed 10 tahun, yang memerlukan mode Full. Ia menyertakan daftar rentang IP Cloudflare supaya log Anda menampilkan alamat asli pengunjung, bukan alamat Cloudflare.
- Satu token Cloudflare, dan panel mengelola sekumpulan opsi Cloudflare untuk Anda. Panel menampilkan nilai yang diinginkan versus nilai live untuk tiap item, plus sinkronisasi push atau pull. Aturan Anda sendiri tetap selamat saat penulisan.
- Halaman firewall yang mencetak aturan persis untuk server Anda, plus kedua daftar rentang Cloudflare dan perintah untuk memeriksanya. Panel tidak pernah menyentuh firewall milik penyedia Anda.
Kenapa penting: kegagalan HTTPS adalah pembunuh senyap klasik — sertifikat yang kedaluwarsa di hari Sabtu ikut membawa tokonya tumbang.
Mengirim perubahan kode
Dua jenis pembaruan yang tidak pernah tertukar satu sama lain.
- Push untuk deploy. Webhook bertanda tangan dari git host Anda memulai deploy.
- Deploys → Update memindahkan kode 6amMart Anda. Settings → self-update memindahkan SixPanel. Keduanya tidak menyentuh file pengaturan Anda, folder data/ Anda, atau database Anda.
- Riwayat dan rollback, dengan 30 deploy terakhir disimpan.
- Pengaman kondisi bersih. Kalau Anda mengedit file di server, pembaruan menolak jalan dan menyebutkan file-nya alih-alih menimpa pekerjaan Anda.
Kenapa penting: menit-menit paling berisiko dalam menjalankan toko adalah menit-menit tepat setelah "deploy" — yang ini membuatnya membosankan.
Tidak kehilangan apa pun
Terjadwal, inkremental, dan dibuktikan seminggu sekali alih-alih diasumsikan.
- Cadangan inkremental (restic), sesuai jadwal, dengan retensi.
- Empat tujuan: server yang sama, S3, SFTP, atau Google Drive.
- Uji pemulihan otomatis mingguan ke database sekali pakai — data live Anda tidak pernah disentuh, dan hasilnya muncul di halaman Backups sekaligus halaman Health.
- Satu cadangan memuat database setiap proyek, file yang diunggah, dan file pengaturan aplikasi. Ia tidak memuat kode Anda — kode itu kembali dari git.
- Satu sandi cadangan bersama, dibuat sekali dan disimpan di state panel. Kalau hilang, tidak ada cadangan yang bisa dibuka lagi selamanya.
- Diverifikasi lewat pembacaan kode, tidak dijalankan: Pemulihan hanya diverifikasi lewat pembacaan kode, tidak dijalankan, pada putaran 15 Agustus. Lihat juga dua batasan pemulihan di bagian bawah — merekalah alasan hal ini penting.
Kenapa penting: backup yang tidak pernah dibuka hanyalah harapan, bukan backup. Uji restore mingguan itulah bedanya.
Menjalankannya sehari-hari, tanpa harus jadi sysadmin
Panel menyebutkan masalahnya dan memberi Anda tombolnya.
- Halaman Health: sekitar 20 pemeriksaan, dikelompokkan menjadi perlu perhatian, sehat, dan informasi, masing-masing dengan satu kalimat akibat dan satu tombol perbaikan. Tiap pemeriksaan dibatasi 2 detik dan seluruh halaman 10 detik, jadi satu pemeriksaan yang menggantung tidak bisa menggantungkan halaman.
- Tiga sumber tidak sepakat soal jumlah itu. Manual yang dikirim menyebut “lebih dari dua puluh”, inventaris kode menghitung sekitar 20 pemeriksaan, dan spesifikasi halaman yang lebih lama menyebut sekitar lima belas. Halaman ini mencetak sekitar 20 — angka terendah dari dua yang berpijak pada produk yang benar-benar dikirim.
- Watchdog yang memulai ulang service yang berjalan tapi tidak bekerja. Process supervisor tidak akan memulai ulang sesuatu yang hidup tapi rusak, karena tidak ada yang crash. Loop SixPanel sendiri melakukan, dan pemeriksaannya menguji apakah pekerjaan selesai daripada apakah prosesnya ada.
- Mesin pekerjaan. Satu pekerjaan panjang pada satu waktu, sisanya mengantre. Lognya mengalir langsung ke peramban. 20 pekerjaan terakhir disimpan, masing-masing 2.000 baris.
- Penyunting berkas setelan untuk aplikasi Anda yang mempertahankan komentar, urutan, dan baris-baris lain milik Anda, memberi tiap kunci jenis masukan yang tepat, dan menandai kunci yang dikelola tumpukan sebagai hanya-baca.
- Pengelola berkas yang dipagari tepat pada dua folder: kode panel admin Anda dan kode toko Anda.
- phpMyAdmin sesuai permintaan — dinyalakan dan dimatikan dari halaman Database, tidak pernah dibiarkan berjalan.
- Perekam kueri lambat yang bisa Anda nyalakan dan kosongkan dari halaman Database.
- Perintah sixpanel di server, lengkap dengan halaman manual, contekan, menu bernomor, pencocok “mungkin maksud Anda”, dan pelengkapan otomatis shell.
- Manual pelanggan lengkap di dalam panel, di balik login yang sama — 24 halaman tugas.
- Paket dukungan dalam satu perintah. Ia mengumpulkan versi, hasil pemeriksaan kesehatan, status layanan, pemakaian disk, dan 500 baris terakhir dari setiap log. Sebelum ditulis, berkas setelan Anda dipangkas menjadi nama kunci saja, berkas status panel tidak diambil sama sekali, dan kode rahasia pada tautan panel Anda beserta nilai-nilai berbentuk kata sandi disamarkan.
Kenapa penting: panel yang benar-benar Anda buka setiap hari seharusnya menjawab "apakah semuanya baik-baik saja?" dalam sekali pandang, bukan satu jam.
Memberi akses ke orang lain
Akses berbatas waktu alih-alih menyerahkan sandi Anda.
- Login sementara untuk developer: nama dan sandinya sendiri, kedaluwarsa setelah 1 jam, 8 jam, 24 jam, atau 7 hari, sampai 20 aktif sekaligus. Sandinya ditampilkan tepat sekali. Mereka bisa menjalankan situs. Mereka tidak bisa mengubah siapa yang boleh masuk, dan tidak bisa membaca rahasia Anda.
- Login demo baca-saja untuk memperlihatkan panel kepada seseorang. Sesi dua jam, setiap penulisan ditolak, nilai sensitif ditutupi.
- Log aktivitas, dan daftar sesi aktif yang bisa Anda cabut satu per satu atau sekaligus.
- Diverifikasi lewat pembacaan kode, tidak dijalankan: Log aktivitas tidak mencakup semuanya. Membuat, mengedit, dan menjalankan manual sebuah tugas terjadwal semuanya dicatat, tetapi menghapusnya sama sekali tidak menulis catatan audit.
Kenapa penting: kebanyakan pembobolan panel tidaklah cerdik — cuma kata sandi yang tertebak di halaman login yang terlihat. Yang satu ini tidak terlihat.
Lebih dari satu toko di satu server
Dipisahkan secara konstruksi, bukan secara kesepakatan.
- Setiap proyek mendapat user unix sendiri, database sendiri dan user database sendiri, folder aplikasi sendiri, konfigurasi site sendiri dan instance cache sendiri di socket sendiri — jadi satu toko tidak dapat membaca cache secret toko lain, dan mengosongkan cache di satu tidak pernah bisa mengosongkan cache lain.
- Dua proyek tidak mungkin berakhir berbagi basis data: namanya diturunkan dari slug unik yang sudah divalidasi.
- Siapkan kira-kira 2 GB RAM tambahan dan 1–2 inti tambahan per toko ekstra — anggarkan 2 inti, ujung atas rentang itu, karena kekurangan sumber daya adalah kesalahan yang mahal.
Kenapa penting: toko kedua milik sebuah agensi seharusnya tidak bisa membaca data toko pertama bahkan secara teori — di sini itu ditegakkan oleh kernel, dan kami menyerangnya sendiri untuk memastikan.
Kecepatan yang sudah dikonfigurasi
Micro-cache lima detik di web server di mesin Anda sendiri, dibentuk sesuai pola permintaan 6amMart.
- Cache lima detik di nginx untuk daftar tetap public catalog endpoint. Jika 100 permintaan tiba di config endpoint dalam satu jendela lima detik, cache mengubahnya menjadi satu startup PHP daripada 100 — itu adalah aritmetika dari jendela cache, bukan hasil throughput terukur. Storage dibatasi 64 MB, dengan eviksi idle 60 detik.
- Kenapa ini penting justru di sini: tokonya dirender di server, jadi setiap halaman yang dibuka pembeli menjadi beberapa panggilan API balik ke mesin yang sama, dan setiap cold start aplikasi ponsel adalah 15–20 panggilan API lagi.
- Ia tidak pernah menyajikan respons personal atau respons pengguna yang sudah masuk. Header Authorization apa pun melewatinya. Cookie apa pun melewatinya. nginx menolak menyimpan respons apa pun yang membawa Set-Cookie. Daftar tolak terpisah mencakup admin, panel vendor, login, checkout, keranjang, pesanan, dan callback pembayaran.
- Zona, modul, dan bahasa menjadi bagian dari kunci cache, jadi toko satu kota tidak akan pernah disajikan ke kota lain.
- Ia menjaga toko tetap hidup saat PHP tidak. Kalau pool PHP macet, nginx menyajikan salinan yang sedikit basi dan menyegarkannya di latar — toko yang tetap jalan, bukan tembok galat 502.
- Semuanya ikut hardware juga: database, compiled-code cache PHP, cache memory dan web-server buffer semua diukur autotune dari mesin asli.
- Tingkat batas permintaan yang disetel untuk jaringan nyata. Ketat pada login, OTP, dan reset kata sandi; lebih longgar untuk penelusuran biasa; terpisah untuk pencarian dan untuk penulisan keranjang dan pesanan. Dokumentasinya menyebut ini apa adanya — perisai banjir permintaan, bukan perlindungan DDoS — karena batas per alamat tidak bisa presisi ketika satu kota berbagi satu IP operator.
- “Edge” di situs ini berarti Cloudflare, yang memang lapisan edge sebenarnya. Cache ini bukan itu, dan tidak disebut begitu.
Kenapa penting: kecepatan adalah satu-satunya hal yang dirasakan pelanggan di setiap kunjungan — dan alasan angka-angka ini diterbitkan beserta metodenya.
Bagian opsional
Nyalakan saat toko membutuhkannya.
- Pelacakan pesanan langsung lewat websocket (Reverb).
- Situs web pelanggan Next.js opsional, dengan aset statisnya disajikan sebagai immutable.
- Berjualan lewat aplikasi mobile saja, tanpa situs web, adalah bentuk yang didukung.
Kenapa penting: alat yang jarang Anda butuhkan seharusnya tidak memakan apa pun saat menganggur — yang ini menyala saat diminta dan menyingkir setelahnya.
Shop check-up (SixPreflight, termasuk)
Ia memeriksa pengaturan di dalam toko Anda, berbeda dari server yang diurus SixPanel.
- SixPreflight ikut disertakan dan dipasang di dalam panel sebagai halaman Shop check-up. Ia membawa sekitar 134 pemeriksaan, skor berbobot, dan nilai huruf.
- Kenapa 134 dan bukan angka yang lebih besar: tiga sumber internal memberi tiga jawaban. Hitungan langsung kunci pemeriksaan unik di kode memberi 163; dokumen serah terima teknis mencatat 134–136 dan menyuruh memakai yang lebih rendah; spesifikasi halaman yang lebih lama menyebut sekitar 100. Halaman ini menulis ~134, angka terendah yang masih dibela sebuah sumber terkini.
- Saat berjalan di dalam SixPanel, perilakunya sengaja berubah: blok config yang bisa disalin-tempel hilang untuk lapisan yang dimiliki panel, dan pengaturan yang menjadi milik panel admin toko Anda dinilai terpisah dari server.
Kenapa penting: server bisa saja sempurna sementara satu pengaturan keliru di dalam toko diam-diam menggerus pesanan — sepasang mata kedua membaca pengaturan-pengaturan itu.
Yang berjalan sendiri
Peta otomatisasinya
"Otomatis" adalah kata yang mudah dicetak. Ini daftar lengkap pekerjaan yang dijalankan panel tanpa Anda — apa yang memicu masing-masing, dan apa yang seharusnya Anda kerjakan sendiri di tengah malam.
- Sekali, di awal
Seluruh server, dari satu perintah
Satu kali tempel di server Ubuntu yang masih kosong memasang web server, database, PHP, cache, queue worker, scheduler, server websocket, dan panelnya sendiri — masing-masing disesuaikan dengan mesin tempatnya dipasang. Anda mengetik satu domain; sisanya ditempatkan, dikonfigurasi, dan dijalankan.
- Sebelum kedaluwarsa
HTTPS yang memperbarui dirinya sendiri
Sertifikat diterbitkan otomatis — lewat DNS bila domain dikelola Cloudflare, sehingga sudah berfungsi bahkan sebelum internet bisa menjangkau servernya — dan setiap pembaruan memuat ulang web server lewat hook per-sertifikat, jadi satu sertifikat yang rusak tidak akan pernah membekukan yang lain.
- Sesuai jadwal Anda
Backup yang benar-benar berjalan
Backup inkremental sesuai jadwal yang Anda tentukan, ke server yang sama, S3, SFTP, atau Google Drive, dengan retensi diterapkan setelah setiap kali berjalan. Database, file unggahan, dan pengaturan setiap proyek — kodenya kembali dari git.
- Setiap minggu
Uji restore, bukan pesan sukses
Seminggu sekali panel memulihkan backup terbaru ke sebuah database sekali pakai dan menghitung barisnya. Backup yang ternyata tidak bisa dibuka membuat halaman Health menjadi merah — karena pesan sukses bukanlah bukti.
- Tiap beberapa menit
Pemulihan mandiri untuk kegagalan yang senyap
Watchdog me-restart layanan yang masih berjalan tapi rusak — kasus yang sepenuhnya luput dari supervisor biasa, karena tidak ada yang crash. Setiap restart yang dilakukannya muncul di log aktivitas beserta alasannya.
- Saat install dan update
Tuning yang disesuaikan dengan mesin
Buffer pool database, memori cache, ukuran tabel sementara, dan worker PHP dihitung dari memori dan core mesin yang sebenarnya — satu tangga ukuran, diukur pada 36 konfigurasi server, diterapkan secara identik oleh installer dan panel.
- Setiap malam
Bersih-bersih database
Penyapuan tiap malam membersihkan baris kedaluwarsa yang tidak pernah dihapus oleh aplikasinya sendiri, dan pada hari Minggu tabel-tabel dioptimalkan — hanya bila ruang disk memungkinkan, dan dengan setiap hasil diperiksa, bukan diasumsikan.
- Di setiap deploy
Indeks yang terukur, dijaga tetap terpasang
Satu paket indeks database — masing-masing diukur pada toko nyata dengan 66,701 pesanan sebelum diterima masuk — diperiksa dan diterapkan ulang setelah setiap perubahan kode. Diperiksa dari apa yang dicakup tiap indeks, bukan dari namanya, sehingga indeks yang diganti namanya tidak bisa mengelabuinya.
- Di setiap git push
Push-to-deploy, dari ujung ke ujung
Push ke repositori Anda dan toko memperbarui dirinya sendiri: pull, dependensi, migrasi database, config cache dibangun ulang hanya bila itu terukur aman untuk kode Anda yang persis itu, PHP dimuat ulang tanpa menjatuhkan satu request pun. Tombol rollback menyimpan rilis sebelumnya.
- Terus-menerus
Pemeriksaan kesehatan yang menyebutkan solusinya
Lebih dari tiga puluh pemeriksaan berjalan dengan jadwalnya masing-masing — layanan, disk, sertifikat, DNS, Cloudflare, file-file panel sendiri dibandingkan dengan rilis yang mengirimkannya. Baris yang gagal menyebutkan solusi persisnya, bukan sekadar masalahnya.
- Saat butuh Anda
Email yang menghormati inbox Anda
Paling banyak satu email per masalah setiap enam jam, dengan kesimpulan berwarna yang terbaca langsung dari pratinjau inbox — dan tanda hijau "selesai" saat masalahnya beres, sehingga diamnya email tidak pernah perlu ditafsirkan.
- Saat tombol ditekan
Update satu tombol, terverifikasi tanda tangan
Satu tombol mengambil rilis, memverifikasi tanda tangannya terhadap kunci yang dipatok di server Anda — host unduhan yang diganti tidak bisa mengganti kunci mesin Anda — menerapkannya, lalu me-restart layanan dalam urutan terukur yang menjaga toko tetap melayani.
Pola di balik semuanya: panel mengerjakan tugasnya, mencatat apa yang dilakukannya, dan memeriksa hasilnya sendiri — dan apa pun yang tidak bisa diverifikasinya, dilaporkan alih-alih diklaim.
Di balik kap mesin
Rekayasa canggih yang berjalan sendiri
Tidak ada satu pun dari ini yang sekadar centang di daftar fitur. Masing-masing adalah mesin sungguhan dengan perilaku terukur, aturan keselamatan ketat, dan laporan yang bisa Anda baca.
Supervisor yang memulihkan diri
Loop 60 detik memperbaiki hal-hal yang benar-benar merusak toko live: antrean macet, sertifikat kedaluwarsa, mode pemeliharaan yang terlupa. Dibatasi aturan ketat — tidak pernah menyalakan yang Anda hentikan, dan tidak pernah bertindak saat deploy atau backup berjalan.
Backup inkremental terenkripsi
Dibangun di atas restic: setiap eksekusi hanya menyimpan yang baru atau berubah sejak sebelumnya, terdeduplikasi dan terenkripsi — backup harian tetap cepat dan kecil, dan setiap snapshot bisa dipulihkan utuh. Tujuan: disk lokal, S3, SFTP, Google Drive.
Backup dibuktikan, bukan diasumsikan
Job backup yang hijau bukanlah bukti. Verifikasi terjadwal membuka snapshot terbaru dan memeriksa bahwa dump database Anda benar-benar ada di dalamnya — jawaban jujur untuk “bisakah saya pulihkan?” datang dari artefaknya, bukan dari kode keluar.
Disetel ke server Anda, otomatis
Satu tangga ukuran yang terukur menghitung buffer pool database, memori Redis, dan jumlah worker PHP dari RAM dan CPU mesin Anda — saat instalasi, dan lagi saat Anda mengubah ukuran. Installer dan panel berbagi satu definisi, dijaga oleh gerbang build.
Micro-cache yang terbukti aman
Endpoint API tersibuk dijawab dari cache nginx — dari 16,9 md menjadi 0,6 md, terukur — tetapi hanya endpoint yang terbukti tak bergantung pemanggil yang boleh masuk: gerbang statis membaca handler aplikasi dan probe langsung tiga lengan memastikan tak ada pelanggan yang bisa melihat data pelanggan lain.
Setiap proyek terisolasi penuh
Setiap toko punya user unix sendiri, pool PHP-FPM sendiri, dan instans Redis sendiri dengan kata sandi; worker-nya berjalan dalam sandbox systemd dengan sistem hanya-baca dan tanpa eskalasi hak. Proyek yang dibobol tidak bisa membaca proyek lain.
Pembaruan bertanda tangan kriptografis
Setiap rilis membawa manifes bertanda tangan ed25519 dengan tanggal kedaluwarsa. Panel menolak apa pun yang tak bertanda tangan, basi, atau ditandatangani kunci yang salah — dan kunci yang dirotasi harus membuktikan diri terhadap rilis sebelum dipercaya.
Membaca aplikasi Anda sebelum bertindak
Panel tidak menegaskan apa pun secara buta. Caching konfigurasi diputuskan dengan membaca kode 6amMart Anda sendiri, sehingga build yang membaca pengaturan saat runtime tak pernah rusak diam-diam. Kode CodeCanyon asli dan build teroptimasi sama-sama mendapat jawaban yang benar.
Pemulihan otomatis, backup inkremental, pembaruan bertanda tangan — Anda tidak mengonfigurasi satu pun. Memang begitulah panel ini dibangun.
Kenapa terasa mudah
Mudah itu keputusan desain, bukan lapisan cat
Semua ini bukan mode sederhana yang menyembunyikan kontrol sesungguhnya. Ini kontrol yang sesungguhnya, ditata agar langkah berikutnya selalu jelas.
Satu kali tempel, tanpa prasyarat
Tidak ada Docker yang harus dipelajari, tidak ada file compose, tidak ada ilmu turun-temurun soal SSH. Stack-nya adalah paket bawaan Ubuntu yang diawasi systemd, dan satu perintah memasang semuanya.
Wizard yang menyarankan jawabannya sendiri
Enam langkah — dasar-dasar, kata sandi, domain, HTTPS, aplikasi, backup. Setiap langkah mengusulkan jawaban yang masuk akal; sebagian besar proses setup adalah mengonfirmasi, bukan memutuskan.
Ketik satu domain, dapatkan seluruh rencananya
Dari satu domain saja, panel merencanakan host dashboard, storefront, dan websocket, record DNS yang perlu dibuat, dan mana di antaranya yang harus di-proxy Cloudflare. Nama yang diam-diam akan merusak HTTPS ditolak, disertai ejaan yang berfungsi.
Masalah datang bersama solusinya
Tidak ada sekadar "gagal". Baris merah memberi tahu Anda pengaturan, file, atau tombol persis yang menyelesaikannya — bedanya antara daftar tugas dan teka-teki.
Setiap aksi adalah job yang bisa Anda pantau
Install, deploy, backup, dan perbaikan berjalan sebagai job dengan log langsung. Tombol menampilkan spinner selagi bekerja, dan sebuah job menolak melaporkan sukses kecuali pemeriksaan ulangnya sendiri lolos.
Buku panduannya hidup di dalam panel
Setiap tautan Help mendarat di halaman tentang hal yang sedang Anda lihat. Buku panduan yang sama disertakan dalam unduhan dan diterbitkan di situs ini.
Command line untuk hari yang buruk
Perintah sixpanel di server mencerminkan panelnya — lengkap dengan man page dan shell completion — untuk hari ketika browser bukan pilihan.
Berbicara dalam bahasa Anda
Delapan bahasa. Datang dari situs ini dan panel terbuka dalam bahasa yang sedang Anda baca; ikuti tautan kembali dan situs ini melakukan hal yang sama.
Tiga hal yang tidak dilakukan orang lain
Tiga klaim, masing-masing dengan alasan itu benar daripada adjektif
Kami membandingkan diri kami dengan rival yang sudah distel sempurna, dan mempublikasikan dari mana kemenangan itu berasal
Siapa saja bisa mempublikasikan benchmark yang mereka menang. Test yang layak dijalankan adalah satu tempat pihak lain diatur dengan benar — jadi box aaPanel distel terlebih dahulu: compiled-code cache berlipat ganda, database buffer pool empat setengah kali lebih besar, worker dikoreksi dari over-committed 50 menjadi sized 14. PHP 8.4 dan JIT compiler-nya sengaja dibiarkan switch on, karena itu adalah keuntungannya.
Kesenjangan tidak menutup. 1.65× / 1.80× terhadap box seperti itu ship; 1.76× / 1.82× terhadap yang distel. Itu bergerak sedikit ke arah lain.
Kemudian perbedaan dipisah satu variabel pada satu waktu. Sekitar 60% adalah pembatasan direktori PHP tunggal, sekitar 8% adalah mode JIT compiler yang salah, dan versi PHP bernilai persis apa-apa. Sekitar 32% masih tidak dijelaskan, dan dipublikasikan sebagai tidak dijelaskan daripada dikreditkan kepada kami.
Kenapa ini berarti: Rasio tanpa penyebab di belakangnya adalah angka marketing. Ini punya penyebab terukur untuk dua pertiga dari diri sendiri dan pengakuan untuk sisanya.
Kami mengukur tiga sistem operasi, hasilnya seri, dan kami mempublikasikan hasil seri itu
Tiga server dari satu provider, dipesan bersama, identik kecuali sistem operasi. Perangkat lunak sama, tuning sama, data sama — database toko asli dengan 66.701 pesanan. Round ini bertanya sistem operasi mana, bukan runtime mana; itu dijalankan pada yang container.
Hasilnya seri. Selisih antara ketiga mesin (3,5 %) lebih kecil daripada selisih satu mesin dengan dirinya sendiri pada dua kali menjalankan konfigurasinya sendiri (8,6 %).
Jadi rekomendasinya diputuskan berdasarkan berapa lama tiap sistem terus menerima pembaruan keamanan, bukan berdasarkan kecepatan. Dan laporan itu membuang baris-barisnya sendiri yang paling menyanjung karena secara aritmetika mustahil.
Kenapa ini berarti: Kesediaan mempublikasikan hasil negatif adalah bukti bahwa metodenya nyata. Siapa pun bisa mempublikasikan benchmark yang dia menangkan.
Caching dan pembatasan yang dibentuk sesuai pola permintaan 6amMart
Micro-caching nginx tersedia untuk siapa saja. Yang khusus di sini adalah semua yang mengelilinginya, dan tidak satu pun bisa ditulis orang yang tidak mengenal aplikasi ini:
- Daftar izin berisi persis endpoint publik mana yang boleh di-cache, dicocokkan pada URI mentah, dengan default menolak.
- Zona, modul, dan bahasa di dalam kunci cache, karena 6amMart menyajikan toko berbeda ke kota berbeda dari URL yang sama.
- Lima aturan lewat yang membuat respons personal mustahil di-cache.
- Tingkatan laju permintaan yang memisahkan login dan OTP dari penjelajahan, dari pencarian, dari penulisan keranjang.
- Timeout yang sengaja dipatok satu sama lain — PHP 120 s, baca nginx 120 s, worker terminate 130 s — karena 6amMart menjalankan ekspor Excel, impor massal, dan laporan toko berat di dalam permintaan web, bukan di latar belakang.
Kenapa ini berarti: Banjir pencarian tanpa autentikasi dulu bisa memenuhi server cache dan mulai menggusur sesi, diam-diam mengeluarkan pembeli yang sudah masuk. Butuh sekitar 278 permintaan, kira-kira 67 detik pada satu koneksi, di mesin uji 8 GB berisi dua proyek. Itu diukur, dibatasi, lalu diukur lagi di mesin yang sama — pada tiga banjir permintaan yang ditabulasikan file bukti, nol penggusuran, sesi tetap hidup setiap kali.
SixPanel dibandingkan
SixPanel dibandingkan dengan aaPanel, CloudPanel, dan mengerjakannya sendiri
Ini perbandingan untuk satu tugas: menjalankan toko 6amMart. Ini bukan perbandingan panel-panel tersebut secara umum, dan tidak jujur kalau disajikan seperti itu.
Persisnya apa yang kami punya tentang dua pesaing, dinyatakan tepat
Tabel punya 14 baris dan dua kolom kompetitor, jadi 28 sel kompetitor. Empat dari 28 itu mengatakan sesuatu selain 'kami belum test ini', dan di sini setiap satu:
- Satu sel mencatat sesuatu yang kami saksikan produk kompetitor lakukan. aaPanel sengaja mengembalikan document root setiap kali pengaturan site disimpan — dicatat pada install yang live. Itu baris Document root, kolom aaPanel.
- Dua sel bertumpu pada perilaku pihak ketiga yang kami verifikasi, bukan pada pengujian panel-panelnya. Arsip Ubuntu 26.04 maupun Debian 13 tidak membawa MariaDB 10.11, dan kedua panel memasang basis data dari paket host — jadi di rilis-rilis itu keduanya tidak bisa menyediakan versi tersebut. Runtime native SixPanel mengambil 11.8 dari arsip yang sama sebagai gantinya, dan SixPanel Docker membawa 10.11 di dalam image-nya. Itulah baris MariaDB 10.11, di kedua kolom pesaing.
- Satu sel melaporkan pengukuran kami sendiri dari kompetitor. aaPanel dipasang pada hardware identik dengan data toko yang sama, distel oleh kami terlebih dahulu, dan diukur — itu baris Speed, kolom aaPanel, dan seluruh metode di atas. CloudPanel tidak diukur, jadi sel-nya mengatakan begitu.
- 24 sel kompetitor sisanya semua mengatakan 'tidak ditest oleh kami'. Itu wording literal, di setiap satu — dihitung, bukan diasumsikan.
Kami tidak mengklaim apa pun tentang usia kedua pesaing. Tidak ada sumber dalam kumpulan ini yang menetapkan usia produk mana pun, jadi klaim semacam itu tidak muncul. Yang bisa dikatakan baris Rekam jejak dengan jujur hanyalah apa yang kami tahu tentang usia kami sendiri.
Kami sekarang telah membandingkan SixPanel dengan aaPanel — hardware identik, data toko yang sama, dan aaPanel distel sebelum angka diambil. Metode dan setiap gambar di atas. CloudPanel tidak diukur sama sekali, dan tidak ada klaim kecepatan tentangnya muncul di mana pun di halaman ini.
| Untuk tugas menjalankan 6amMart | SixPanel | aaPanel | CloudPanel | Server biasa, dikerjakan sendiri |
|---|---|---|---|---|
| Dibangun untuk apa | Satu aplikasi saja — 6amMart | Web hosting general-purpose — tidak ditest oleh kami; baca daftar fitur vendor sendiri | Web hosting general-purpose — tidak ditest oleh kami; baca daftar fitur vendor sendiri | Apa pun yang Anda bangun |
| Kecepatan, hardware dan toko yang sama | Diukur: 1.76× lebih cepat daripada aaPanel yang sudah distel sempurna pada satu permintaan, 1.82× dengan empat sekaligus, di seluruh endpoint yang mencapai PHP di keduanya | Perbandingan di atas. Kami memasangnya, menyelnya, dan membiarkan PHP 8.4 dan JIT-nya tetap berada di tempat | Tidak ditest oleh kami — tidak ada klaim kecepatan tentangnya | Apa pun yang insinyur Anda capai |
| MariaDB 10.11 pada Ubuntu 26.04 / Debian 13 | Dengan runtime Docker, ya — image-nya dipatok pada 10.11 apa pun yang dijalankan host. Runtime native mengambil MariaDB 11.8 dari arsip milik rilis-rilis itu sebagai gantinya, dan diukur melawan 10.11 pada toko yang sama itu seri. | Tidak tersedia. Tidak satu pun dari kedua rilis itu membawa 10.11 di arsipnya, dan panel ini memasang dari paket host | Tidak tersedia — alasan sama | Hanya jika Anda menjalankan container sendiri |
| Website lain, mail, DNS, FTP di box yang sama | Tidak. Installer menolak server yang sudah menjalankan aaPanel, CloudPanel, cPanel atau Plesk, atau punya apa saja di port 80/443 | Mereka menang di sini. Ini untuk apa panel general — tidak ditest oleh kami; periksa vendor | Mereka menang di sini — tidak ditest oleh kami; periksa vendor | Mungkin, dan sepenuhnya masalah Anda |
| User, roles, teams | Tidak. Satu akun admin. Plus login sementara dan satu demo login read-only | Mereka menang di sini. Tidak ditest oleh kami; periksa vendor | Mereka menang di sini. Tidak ditest oleh kami; periksa vendor | Apa pun yang Anda config |
| Distel untuk aplikasi ini dari kotak | Autotune menulis PHP worker, database buffer pool, cache memory, temporary table, buffer dan redo log dari mesin asli, 1 core / 2 GB → 16 core / 32 GB — dan kedua tempat yang menghitung itu diperiksa satu sama lain pada setiap build | Tidak ditest oleh kami; periksa vendor | Tidak ditest oleh kami; periksa vendor | Apa pun yang Anda tahu |
| Micro-cache berbentuk 6amMart | Built in: allowlist, zone/module/language di key, 5 bypass, stale-serve saat PHP wedge | nginx micro-caching tersedia di mana saja — seseorang harus menulis aturan spesifik 6amMart. Tidak ditest oleh kami | Sama. Tidak ditest oleh kami | Sama |
| Backup | restic, dijadwalkan, retention, empat tujuan, test restore otomatis mingguan | Tidak ditest oleh kami — bandingkan test restore otomatis secara khusus | Tidak ditest oleh kami — sama | Apa pun yang Anda script |
| HTTPS Gratis | Ya, dengan pembaruan otomatis dan penerbitan sadar Cloudflare | Tidak ditest oleh kami; periksa vendor | Tidak ditest oleh kami; periksa vendor | certbot, oleh Anda |
| Deploy | Push ke git; history dan rollback dengan 30 deploy terakhir disimpan; menolak menimpa edit Anda | Tidak ditest oleh kami; periksa vendor | Tidak ditest oleh kami; periksa vendor | Apa pun yang Anda script |
| Document root tetap di mana Anda meletakkannya | Ya | Dicatat pada live install: aaPanel diam-diam mengembalikan document root setiap kali pengaturan site disimpan | Tidak ditest oleh kami | Milik Anda untuk dapati dengan benar |
| Track record | SixPanel ada di release saat ini, dan itu baru. Kami tidak bisa tunjukkan tahun yang tidak kami miliki | Tidak ditest oleh kami; periksa berapa lama vendor ship | Tidak ditest oleh kami; periksa berapa lama vendor ship | Linux 30+ tahun |
| Source yang dapat dibaca di server Anda | Mereka mungkin menang di sini. Backend panel ship sebagai V8 bytecode dengan source yang dapat dibaca dihapus. Kami sebut itu deterrence, bukan security | Tidak ditest oleh kami; periksa vendor | Tidak ditest oleh kami; periksa vendor | Semuanya dapat dibaca |
| Siapa yang memperbaikinya saat rusak | Halaman kesehatan nama perbaikannya; bundle support dalam satu perintah | Tidak ditest oleh kami; periksa support apa vendor tawarkan | Tidak ditest oleh kami; periksa support apa vendor tawarkan | Anda |
Tidak ada baris harga karena tidak ada harganya. SixPanel gratis, diterbitkan di CodeCanyon, dan perintah instalasinya adalah perintah publik yang sama untuk semua orang — tanpa kunci untuk dimasukkan, tanpa kode untuk ditempel, tanpa perlu mendaftar apa pun. Instalasi dan penyiapan pertama juga gratis. Pembaruan datang lewat CodeCanyon, dan panelnya juga bisa memperbarui dirinya sendiri.
Kapan aaPanel atau CloudPanel adalah pilihan yang lebih baik
Lima kasus nyata. Kalau salah satunya adalah Anda, belilah panel serbaguna dan jangan beli yang ini:
- 1Anda ingin lebih dari satu situs web di server itu. SixPanel mengambil seluruh mesin dan menolak berbagi.
- 2Anda butuh hosting mail, DNS, atau FTP di mesin yang sama. SixPanel sama sekali tidak menyediakannya.
- 3Anda butuh beberapa akun staf dengan izin berbeda. SixPanel punya satu akun admin dan tanpa peran.
- 4Anda menjalankan sesuatu selain 6amMart. Setiap keunggulan di halaman ini berasal dari mengenal satu aplikasi dengan baik.
- 5Rekam jejak produksi yang panjang adalah kriteria utama Anda. SixPanel masih baru. Itu alasan yang wajar untuk menunggu.
Dan satu lagi untuk yang mengerjakannya sendiri: kalau Anda punya sysadmin, server rakitan tangan tidak lebih buruk. Insinyur yang kompeten bisa menyetel MariaDB, menulis aturan cache, dan membuat skrip cadangan. Yang dihilangkan SixPanel adalah kebutuhan akan orang tersebut, dan kebutuhan untuk ingat memeriksa ulang semuanya.
Sistem operasi
Sistem operasi mana yang dipasang, dan mengapa alasannya sisa masa dukungan bukan kecepatan
Kedua runtime merekomendasikan Ubuntu 26.04 LTS. Ubuntu 24.04 LTS dan Debian 13 adalah dua rilis lain yang didukung.
Bukan karena lebih cepat. Enam sumbu diukur pada perangkat keras identik — sistem operasi, PHP, MariaDB, nginx, Redis, dan kernel — dan tidak ada pertukaran versi yang menghasilkan perbedaan yang layak dilaporkan. Dua mesin identik byte demi byte berselisih 11,6 % satu sama lain di 20 dari 20 baris, jadi ambang deraunya lebih besar daripada efek apa pun yang ditemukan.
Runtime native mengambil PHP, MariaDB, nginx, dan Redis dari arsip distribusi rilis itu sendiri, dan ketiga rilis yang didukung membawa set yang bekerja: Ubuntu 26.04 memberi PHP 8.5 dan MariaDB 11.8, Debian 13 memberi 8.4 dan 11.8, Ubuntu 24.04 memberi 8.3 dan 10.11. Karena kecepatannya seri, sumbu yang tersisa hanyalah berapa lama pembaruan keamanan terus datang — dan 26.04 dipatch sampai April 2031.
SixPreflight merekomendasikan Ubuntu 26.04 LTS, dengan alasan yang sama seperti runtime native.
| Pilihan | SixPanel / SixPanel Docker | SixPreflight |
|---|---|---|
| Direkomendasikan | Ubuntu 26.04 LTS, di kedua runtime | Ubuntu 26.04 LTS |
| Juga didukung | Kedua runtime: Ubuntu 24.04 LTS dan Debian 13. Runtime Docker juga terpasang di Debian 12, yang ditolak runtime native berdasarkan nama | Ubuntu 24.04 LTS, Debian 13 |
| Mengapa | Kecepatannya seri di ketiganya, jadi yang menentukan adalah sisa masa dukungan: 26.04 dipatch sampai April 2031. Runtime native mengambil PHP dan MariaDB dari rilis mana pun yang Anda pilih. | Alasan yang sama: basis data datang dari sistem operasi, setiap rilis yang didukung membawa versi yang bekerja, dan yang tersisa untuk dipilih adalah sisa masa dukungannya. |
Didukung tidak sama dengan diukur. Runtime native mendukung tiga rilis, dan ketiganya diukur — Ubuntu 24.04, Ubuntu 26.04, dan Debian 13. Debian 12 ditolak berdasarkan nama: dukungan keamanan gratisnya berakhir pada Juli 2026. Runtime Docker masih terpasang di sana, dan Anda tetap sebaiknya tidak memulai toko baru di sana, karena kernel, glibc, Docker, dan OpenSSH datang dari arsip host apa pun yang berjalan di dalam container.
Mengapa sekarang semuanya menunjuk ke arah yang sama
Ronde mesin basis data sebelumnya menempatkan MariaDB 10.11 di posisi pertama, dan untuk sementara itu memecah rekomendasinya, karena hanya Ubuntu 24.04 yang membawanya. Diukur ulang pada mesin identik dengan toko 66.701 pesanan yang sama, perpecahan itu sudah hilang.
MariaDB 11.8 melawan 10.11 pada seluruh aplikasi adalah seri. Baris pengukuran yang menyiratkan sebaliknya dibuang, karena perangkat uji mengukur jabat tangan terenkripsi, bukan basis datanya.
Satu-satunya tempat 11.8 tampak lebih lambat sama sekali tidak melakukan pekerjaan.
Itu SELECT 1 — kueri yang tidak melakukan pekerjaan apa pun, dan terbaca 12 ms di satu lengan berbanding 29 ms dan 37 ms di dua lainnya. Lantai yang bergerak tiga kali lipat bukanlah eksekusi kueri: MariaDB 11.8 menegosiasikan TLS di unix socket dan 10.11 tidak, jadi yang terukur adalah jabat tangannya. Diukur langsung: 24 ms per panggilan klien di 11.8 berbanding 6 ms dengan TLS dimatikan dan 10 ms di 10.11. Sebuah toko tidak pernah membayarnya — mysqlnd tidak menegosiasikan TLS di socket, 0,12 sampai 0,21 ms per koneksi.
Angka lama “11.x 2,7× lebih lambat” sama sekali bukan tentang 11.8.
Angka itu datang dari satu kueri laporan pada model biaya MariaDB 11.0, dan ditarik sebagai klaim tentang seluruh aplikasi. Jadi tidak ada lagi yang mendukung mematok rilis yang lebih tua: runtime native mengambil 11.8 dari arsip milik Ubuntu 26.04 dan Debian 13, dan 10.11 dari arsip Ubuntu 24.04.
Satu jawaban, dan itu bukan jawaban kecepatan. Ambil rilis yang paling lama terus dipatch.
Bagaimana pengukurannya dilakukan
- Diukur pada 15 Agustus 2026, pada build tumpukan yang berlaku hari itu. SixPanel sudah merilis versi sejak saat itu, dan tidak ada di bagian ini yang dijalankan ulang pada rilis sekarang. Tanggalnya itulah yang memaku pengukuran ini.
- Tiga server dari penyedia yang sama, dipesan bersamaan, identik kecuali sistem operasinya — yaitu setiap rilis yang didukung runtime native.
- Prosesor yang sama pada ketiganya: 2 × AMD EPYC 7713, 2 inti. RAM 3.915 / 3.910 / 3.921 MB. Disk 79 GB masing-masing.
- Perangkat lunaknya identik byte demi byte di ketiganya — MariaDB 10.11, build PHP yang sama, server web yang sama. Ronde ini dijalankan pada runtime container, dan itulah yang memungkinkannya: runtime itu menahan stack tetap diam sehingga sistem operasi menjadi satu-satunya yang berubah.
- Data nyata, bukan data uji. Basis data toko produksi sungguhan: dump 410 MB yang dipulihkan menjadi 515 MB, 66.701 pesanan, plus 894 MB unggahan sungguhan.
- Pemasangan SixPanel yang segar di tiap mesin, lewat jalur pelanggan yang normal. Tanpa penyetelan manual — autotune memilih setiap nilai, dan ia memilih nilai yang sama di ketiganya.
- Dipanaskan dulu, baru diukur. Sampel pemanasan dibuang; yang dilaporkan adalah jalannya yang kedua.
- Percentiles, not averages.
Permintaan per detik — endpoint pencarian, 20 orang sekaligus, 30 detik
Inilah angka yang layak dipercaya.
| Sistem operasi | Permintaan selesai | Permintaan per detik |
|---|---|---|
| Ubuntu 24.04 | 1,561 | 52.0 |
| Ubuntu 26.04 | 1,616 | 53.9 |
| Debian 13 | 1,595 | 53.2 |
Selisih antara ketiganya: 3.5 %. Mesin Ubuntu 26.04 berbeda dengan dirinya sendiri sebesar 8.6 % pada dua kali pengujian konfigurasi identiknya — 49.6, lalu 53.9.
Catatan aritmetika, karena halaman yang membanggakan diri menangkap angka mustahil tidak boleh mencetak persentase yang tidak bisa dicapai pembaca dari hitungan di sebelahnya. Laporan internal menulis selisihnya 3.7 % dan variasi terhadap dirinya sendiri 8.7 %. Keduanya dibulatkan ke atas, jadi halaman ini mencetak hasil hitung ulang yang dipotong: (1,616 − 1,561) ÷ 1,561 = 3.5234 % → 3.5 %, dan (53.9 − 49.6) ÷ 49.6 = 8.6694 % → 8.6 %. Temuannya tidak berubah — selisih antar mesin tetap lebih kecil daripada perbedaan satu mesin dengan dirinya sendiri. Kolom per detik di atas memakai pembulatan 1 desimal milik sumbernya: 1,616 ÷ 30 = 53.8666 dan 1,595 ÷ 30 = 53.1666 terpotong menjadi 53.8 dan 53.1, dan hanya 52.0 yang memang sudah terpotong. Kolomnya dibiarkan seperti yang dicetak sumbernya supaya kedua file bisa disandingkan; persentasenya milik halaman ini sendiri, dan itulah angka yang dikutip.
Baca seluruh blok ini sebagai “sekitar 53 permintaan per detik pada 2 core, pada endpoint pencarian, dengan 20 pengguna bersamaan, selama 30 detik” — dan tidak lebih dari itu. Setiap syarat itu ikut ke mana pun angka ini diulang di halaman ini.
Latensi saat menganggur — dicatat, dan sengaja tidak dicetak
Latensi serial diukur pada setiap sisi: beranda storefront, login admin, dan endpoint API, satu permintaan pada satu waktu di mesin yang menganggur.
Angka per sel itu tidak ada di halaman ini, dan inilah alasannya. Laporan internal melarang angka “X % lebih cepat” mana pun yang diambil dari tabel tersebut. Tabel tiga kolom berisi nilai milidetik adalah angka itu dengan satu pengurangan: pembaca mana pun yang punya kalkulator, dan setiap peringkas AI yang tidak punya kalkulator, akan menghasilkan perbandingan yang dilarang laporan itu. Mencetak tabelnya lalu menambahkan “tapi jangan bandingkan angka ini” tidak berhasil, karena kutipan menyimpan angkanya dan membuang catatannya.
- Ketiga mesin seri pada angka yang penting, dan satu mesin berbeda dengan dirinya sendiri lebih besar daripada perbedaan antar ketiganya.
- Perbedaan kecil yang konsisten memang muncul pada latensi serial menganggur di satu sisi. Itu tercatat dalam laporan internal dan sengaja tidak diklaim, karena tiga alasan yang disebutkan di sana: bentuknya biaya tetap, bukan proporsional, yang merupakan tanda penungguan alih-alih pekerjaan; perbedaannya hilang sepenuhnya saat ada beban, yaitu justru saat hal itu akan berarti; dan dengan satu mesin per sistem operasi, versi kernel dan mesin fisik tertentu itu tidak bisa dipisahkan.
- Baris persentil di bawah beban dari dua sisi dibuang seluruhnya.
Ada baris yang dibuang, dan itu penting
Persentil di bawah beban pada sisi Ubuntu 26.04 mustahil secara aritmetika. Dua puluh worker selama 30 detik berarti 600 worker-detik, jadi 1,616 permintaan yang selesai punya rata-rata aritmetika 371 ms. Sisi itu melaporkan p50 sekaligus p99-nya di bawah rata-rata tersebut — p99 yang lebih cepat daripada permintaan rata-rata. Kedua pengujiannya menunjukkan hal yang sama, jadi ini sistematis pada mesin itu, bukan sampel yang tersasar.
Kalau diterima apa adanya, baris-baris itu akan membuat mesin tersebut tampak jauh lebih baik di bawah beban. Tidak — jumlah permintaan selesainya berada dalam 3.5 % dari yang lain. Kedua nilai persentil itu sendiri tidak dicetak di halaman ini: laporan internal menyingkirkan angka latensi di bawah beban milik Ubuntu 26.04 sebagai satu kelompok. Perhitungan di atas sudah cukup untuk menunjukkan kenapa angka itu dibuang, dan pembuangannya itulah intinya.
Harness pengujiannya kini membawa pemeriksaan silang berdasarkan Hukum Little, sehingga sampel yang rusak mengumumkan dirinya sendiri alih-alih menjadi judul berita.
Database, pada kumpulan data nyata 515 MB
Baca catatannya sebelum angkanya. Setiap perbedaan antar mesin di tabel ini masih berada di dalam rentang pengujian-ke-pengujian Ubuntu 24.04 sendiri, yaitu 85–125 ms pada tiga kueri yang sama. Kolom-kolom ini bukan peringkat; ini tiga sampel dari satu angka. Temuan sebenarnya ada di baris terakhir.
| Kueri | Ubuntu 24.04 | Ubuntu 26.04 | Debian 13 |
|---|---|---|---|
| Hitung semua pesanan | 120 ms | 96 ms | 106 ms |
| Hitung semua baris pesanan | 102 ms | 102 ms | 110 ms |
| Pesanan di-join ke baris pesanan, 50 baris | 85 ms | 80 ms | 81 ms |
| Tingkat hit buffer pool | 99.991 % | 99.989 % | 99.987 % |
Baris terakhir itulah temuannya: database 515 MB di dalam buffer pool 1,024 MB berarti sekitar 99.99 % pembacaan dijawab dari memori, dan beban kerja ini berhenti membaca disk begitu sudah panas.
Berapa lama instalasinya
| Sistem operasi | Instalasi tanpa pengawasan | Masalah |
|---|---|---|
| Ubuntu 24.04 | 303 s | tidak ada |
| Ubuntu 26.04 | 281 s | tidak ada |
| Debian 13 | 273 s | git tidak ada di image minimal, sehingga proses clone gagal total — ditemukan di sini, diperbaiki di sini |
303 s adalah lima menit tiga detik, karena itulah halaman ini menulis “sekitar lima menit” dan bukan “kurang dari lima menit”.
Kenapa April 2031 yang menentukan
Karena kecepatannya seri, faktor penentunya adalah berapa lama tiap sistem terus mendapat pembaruan keamanan. Sistem operasi yang habis masa dukungannya adalah satu-satunya peristiwa yang memaksa pembangunan ulang server secara penuh — dan membangun ulang server adalah satu hal yang tidak bisa dilakukan SixPanel untuk pemiliknya.
| Sistem operasi | Dukungan keamanan gratis sampai | Sisa masa sejak Agustus 2026 |
|---|---|---|
| Ubuntu 26.04 LTS | April 2031 | 4 tahun 8 bulan |
| Ubuntu 24.04 LTS | Mei 2029 | 2 tahun 8 bulan |
| Debian 13 | Agustus 2028, lalu LTS komunitas | sekitar 1 tahun 10 bulan |
| Debian 12 — hanya runtime container, tidak direkomendasikan | berakhir Juli 2026 | sudah lewat |
MariaDB 10.11 sendiri habis masanya sekitar Februari 2028. Di runtime container itu adalah patokan image dan keputusan terpisah; di runtime native itu hanya berlaku untuk Ubuntu 24.04, karena 26.04 dan Debian 13 mengambil 11.8 dari arsip mereka sendiri. Bagaimanapun, itulah sebabnya sistem operasi host sebaiknya yang paling jarang perlu diganti.
Kalau perusahaan hosting Anda belum menyediakan Ubuntu 26.04, ambil Ubuntu 24.04. Rilis itu didukung penuh dan Anda tidak kehilangan apa pun yang bisa diukur.
Aman dikatakan, dan halaman ini mengatakannya
- SixPanel menjalankan stack 6amMart lengkap di Ubuntu 26.04, Ubuntu 24.04, dan Debian 13 — tiga yang diukur — diverifikasi pada data produksi nyata.
- Setiap rilis yang didukung membawa basis data yang bekerja di arsipnya sendiri — MariaDB 11.8 di Ubuntu 26.04 dan Debian 13, 10.11 di Ubuntu 24.04 — dan diukur pada toko yang sama, 11.8 melawan 10.11 adalah seri. Runtime container mematok 10.11 di image-nya kalau Anda memang menginginkan versi itu.
- Ubuntu 26.04 LTS direkomendasikan, dan mendapat pembaruan keamanan sampai April 2031.
- Server 2 core / 4 GB melayani sekitar 53 permintaan per detik pada endpoint pencarian, dengan 20 pengguna bersamaan, selama 30 detik, pada katalog seukuran live berisi 66,701 pesanan, dengan database menjawab 99.99 % pembacaan dari memori.
- Instalasi baru selesai tanpa pengawasan dalam sekitar lima menit (273–303 s terukur; yang paling lambat dari ketiganya, 303 s, adalah angka yang dipakai untuk menulis teks ini).
Tidak didukung oleh pengukuran, dan halaman ini tidak mengatakannya
- Bahwa salah satu sistem operasi ini lebih cepat daripada yang lain. Perbedaan yang terukur lebih kecil daripada derau satu mesin.
- Angka persentase lebih cepat mana pun yang diturunkan dari tabel latensi internal. Selisih antar mesin 3.5 % berbanding variasi terhadap diri sendiri 8.6 % — itulah sebabnya tidak ada tabel latensi per sel sama sekali.
- Angka latensi di bawah beban milik Ubuntu 26.04. Angka itu mustahil secara aritmetika dan dikeluarkan.
- Apa pun tentang kecepatan disk. Kolom itu mencerminkan mesin fisik mana yang kebagian tiap server, bukan sistem operasinya — dan itu tidak membeli apa pun ke arah mana pun, karena database menjawab 99.99 % pembacaan dari memori dan berhenti menyentuh disk begitu panas.
- Angka umum “6amMart secepat ini” mana pun. 53 permintaan per detik menggambarkan satu endpoint, pada data ini, pada 2 core, dengan 20 pengguna bersamaan selama 30 detik.
- Apa pun tentang server 8 GB atau lebih besar. Hanya mesin 4 GB yang diukur pada putaran ini.
- Apa pun tentang kecepatan Debian 12. Runtime native menolaknya berdasarkan nama, dan ia tidak pernah diukur.
Apa yang rusak karena putaran ini, dan kami perbaiki
Tiga cacat nyata muncul justru karena pengukuran dijalankan di server nyata dengan data nyata. Ketiganya inilah yang dicatat sumbernya — daftarnya lengkap, bukan pilihan.
- 1Installer gagal di Debian 13. Image minimalnya tidak menyertakan git, jadi proses clone gagal total. Diperbaiki.
- 2Harness pengujian tidak mengukur apa pun pada baris API. Header permintaannya terpecah-pecah, jadi setiap baris API mencetak nol sampel — diam-diam, di ketiga mesin. Diperbaiki, dan pengujian yang tidak mengumpulkan sampel kini menyatakannya dengan keras alih-alih mencetak hasil diam.
- 3Dua script berbeda pendapat soal batas memori PHP, sementara sebuah komentar mengklaim rumusnya sama persis. Sudah dikoreksi.
Bagian ini tetap ada di halaman. Inilah bukti bahwa pengukurannya nyata.
Apa yang Anda butuhkan
Apa yang Anda butuhkan, dan berapa lama instalasi baru sebenarnya
| Kebutuhan | Rincian |
|---|---|
| Sistem operasi | Ubuntu 26.04 (direkomendasikan), Ubuntu 24.04, atau Debian 13 — tepat tiga. Tidak ada yang lain: rilis yang lebih lama, termasuk Debian 12, dan setiap distribusi lain ditolak berdasarkan nama sebelum apa pun diunduh. Dukungan keamanan gratis Debian 12 berakhir pada Juli 2026; runtime container masih terpasang di sana, tetapi toko baru sebaiknya tidak dimulai di situ. |
| Jenis prosesor | x86_64, atau arm64 (ditulis juga aarch64). |
| Core CPU | 2 core adalah ukuran nyaman untuk satu toko. Autotune mendukung 1 core sampai 16 core. |
| RAM | 2 GB adalah minimum praktis. Installer menolak di bawah sekitar 1.2 GB dan memberi peringatan di bawah 2 GB. 4 GB adalah ukuran nyaman untuk satu toko. |
| Disk | Bukan salah satu syarat penolakan installer. Ketiga mesin yang diukur masing-masing punya 79 GB. Panel menolak unggahan yang akan menyisakan ruang kosong kurang dari yang lebih kecil antara 2 GB dan 10 % dari disk. Untuk instalasi 6amMart native (tanpa container), SixPreflight meminta 20 GB kosong dan lebih menyukai 40 GB. |
| Kondisi server | Baru. Tanpa aaPanel, CloudPanel, cPanel, atau Plesk. Tidak ada yang sudah mendengarkan di port 80 atau 443. |
| Port yang dibuka di penyedia Anda | Tepat tiga: port panel Anda (angka tinggi acak yang dipilih saat instalasi), 80, dan 443. Tidak ada yang lain, selamanya. |
| Akses | Login root untuk server itu. Installer menolak dijalankan sebagai siapa pun selain root. |
| Kode Anda | Kode 6amMart Anda di repositori git privat. SixPanel memasang dari git, bukan dari zip. |
| Ponsel Anda | Aplikasi authenticator. Login dua faktor wajib untuk akun pemilik dan tidak bisa dimatikan. |
| Sebuah domain | Dan kemampuan mengedit catatan DNS-nya. |
| Toko kedua | Kira-kira 2 GB RAM tambahan dan 1–2 core tambahan per toko ekstra. Rencanakan pada batas atas rentang itu — 2 core — itu sisi yang konservatif. |
| Berapa biayanya | Tidak ada. SixPanel gratis dan diterbitkan di CodeCanyon, dan instalasi serta penyiapan pertama juga gratis. Tidak ada server lisensi, tidak ada kunci untuk diperbarui, dan tidak ada kode pembelian di dalam perintah instalasi. |
Apa yang SixPanel pasang: nginx, PHP-FPM, MariaDB, Redis, dan layanan panel Node.js, semua diawasi oleh systemd dan semua dari arsip distribusi rilis itu sendiri — PHP 8.5 dengan MariaDB 11.8 di Ubuntu 26.04, 8.4 dengan 11.8 di Debian 13, 8.3 dengan 10.11 di Ubuntu 24.04. Runtime Docker memasang stack yang sama sebagai container, dipatok pada PHP 8.4 dan MariaDB 10.11. Bahasa antarmuka panel: 8 — English, Spanish, Arabic, Portuguese, French, German, Indonesian, Bengali.
Berapa lama instalasi baru sebenarnya — jadwal yang jujur
“Lima menit” itu perintah instalasinya, bukan seluruh pekerjaannya. Perintah instalasinya sekitar lima menit. Dari server sewaan sampai toko hidup butuh sekitar satu jam.
| Langkah | Waktu |
|---|---|
| Taruh kode Anda di repositori git privat (sekali saja, di komputer Anda sendiri) | sekitar 20 menit kalau Anda belum pernah memakai git |
| Perbarui server dan tambahkan tiga alat kecil | satu dua menit |
| Jalankan perintah instalasi — memeriksa sistem, memasang Docker, memverifikasi tanda tangan, mengunduh dan memeriksa file, membuat sandi, memilih port panel acak, mengukur semuanya untuk mesin itu, lalu membangun dan menjalankan | 273–303 detik terukur pada tiga sistem operasi — sekitar lima menit |
| Buka tiga port di dashboard penyedia hosting Anda | beberapa menit |
| Login pertama, dan siapkan dua faktor di ponsel Anda | beberapa menit |
| Arahkan domain dan dapatkan sertifikat gratis | kurang dari satu menit begitu DNS menyebar — mulai catatan DNS lebih awal |
| Pasang kode 6amMart Anda dari git | beberapa menit |
| Total untuk server pertama | Sediakan satu jam. Anda mungkin selesai lebih cepat. |
Apa yang dicetak installer di akhir, dan apa yang harus Anda simpan segera: URL panel lengkap, nama pengguna, dan sandi. Sandinya ditampilkan sekali dan hanya disimpan sebagai hash — sandi itu tidak bisa dibaca kembali.
Kegagalan yang paling sering terjadi bukanlah instalasinya. Melainkan port panel yang tidak dibuka di penyedia hosting.
Keamanan
Keamanan — hanya yang bisa ditunjukkan
Setiap item di sini bisa diperiksa di dalam produknya. Tidak ada di sini yang merupakan pernyataan keamanan secara umum. Celah di bidang ini ada di daftar batas jujur di bawah, tidak disembunyikan.
Sampai ke panelnya saja
- Panel hanya menjawab di bawah alamat rahasia. Selain itu semuanya mengembalikan halaman “tidak ditemukan” yang kosong, jadi pemindai port tidak bisa membedakan panel dari port tertutup. Port panelnya sendiri adalah angka tinggi acak yang dipilih saat instalasi, berbeda di setiap server.
- Alamat rahasia itu adalah gerbang di depan login, bukan pengganti login — nama pengguna, sandi, dan kode dua faktor tetap berjalan di baliknya.
- Kode masuk yang salah dibandingkan dalam waktu konstan, dan dijawab dengan halaman “tidak ditemukan” kosong yang sama seperti apa pun lainnya, setelah jeda tetap 200 ms. Kesalahan itu dihitung ke arah penguncian per alamat. Jedanya dibatasi pada 32 kesalahan yang sedang berjalan; melewati batas itu, “tidak ditemukan” langsung dikembalikan. Jadi kode yang salah berbiaya sama dengan apa pun lainnya sampai batas itu, bukan selalu — 20 kode salah dalam 15 menit tetap mengunci alamat itu selama 30 menit.
- Pada instalasi baru, nama login dibuat otomatis — admin ditambah empat karakter acak, misalnya admin7f3q — sehingga robot yang menemukan halaman login tidak punya nama untuk dibidik. Instalasi yang sudah membawa hash sandi tetap memakai nama biasa admin.
- Kunci domain panel opsional. Saat domain panel disetel, bahkan permintaan langsung ke alamat IP server pun mendapat halaman “tidak ditemukan” kosong yang sama. Jalan masuk kembalinya lewat SSH.
Masuk
- Hashing sandi (bcrypt), cookie sesi bertanda tangan, dan kode dua faktor yang tidak bisa dimatikan untuk akun pemilik.
- Penguncian yang bertahan setelah restart: 20 sandi gagal dalam 15 menit mengunci alamat itu selama 30 menit. Lima kode dua faktor yang salah berakibat sama.
- Daftar izin IP opsional pada form login — dan menyimpan daftar yang tidak memuat alamat Anda sendiri akan ditolak, jadi Anda tidak bisa mengunci diri sendiri di luar.
Apa yang ditolak panel
- Tolak-secara-bawaan pada setiap rute, plus pemeriksaan lintas-situs pada setiap perubahan. Webhook deploy adalah satu-satunya pengecualian dan sebagai gantinya membuktikan dirinya dengan tanda tangan atas isi permintaan mentah. Pengiriman ganda dan pengiriman yang lebih tua dari lima menit diabaikan, dan setiap penolakan ditulis ke log aktivitas.
- File manager tidak dapat mencapai stack. Itu difenced ke dua folder — code admin Anda dan code storefront Anda — dengan prefix check dan real-path check. Folder panel sendiri, folder data dan file setting tidak dapat dijangkau dari API itu. Ini dinyatakan sebagai security boundary, bukan design preference.
- Keputusan kepercayaan memakai peer jaringan yang sebenarnya, tidak pernah header yang bisa ditulis klien.
- Perutean peka huruf besar-kecil disetel sebelum middleware pertama, yang menutup celah nyata ketika sebuah path dengan kapitalisasi berbeda lolos dari pemeriksaan autentikasi yang peka huruf.
Rahasia
- Berkas status panel hanya untuk pemilik (0600) di dalam folder yang juga hanya untuk pemilik. Berkas setelan tumpukan 0600. Soket baris perintah adalah soket Unix milik pemilik — hanya root berdasarkan izin berkas, tidak pernah terbuka lewat jaringan.
- Password first-boot adalah hashed, kemudian dikosongkan dari settings file dan dihapus dari process environment, jadi tidak bisa dibaca kembali setelahnya.
- Pemasangan lewat wizard dulu meninggalkan berkas setelan aplikasi bisa dibaca siapa saja, sambil bicara dengan cache tanpa proteksi. Itu sudah diperbaiki — setiap pemasangan, pembaruan, rollback, dan pemindahan kini menegaskan ulang kunci infrastruktur dan mengunci berkas itu kembali ke 0600.
- Kata sandi SSH yang dipakai untuk pemindahan tidak pernah muncul di daftar proses. Semuanya dilewatkan lewat environment dan dibersihkan dari setiap baris log.
- Paket dukungan disaring sebelum ditulis — setelan dipangkas jadi nama kunci, berkas status panel tidak diambil sama sekali, dan kode rahasia masuk serta nilai berbentuk kata sandi disamarkan.
Menjaga satu toko dari data toko lain
- Setiap proyek berjalan sebagai pengguna unix sendiri, dengan folder aplikasi 0700 dan file pengaturan 0600. Barrier adalah kernel menolak pengguna yang berbeda — bukan check di dalam PHP, yang PHP bug bisa mengitari.
- Setiap proyek juga mendapat pengguna basis data sendiri dengan grants scoped ke schema sendiri, pool worker PHP sendiri di socket sendiri, dan instance cache sendiri dengan password sendiri dan memory ceiling sendiri.
- Ini diuji dengan menyerangnya daripada dipertegas. Setiap pembacaan cross-project sebenarnya dicoba dari dalam PHP proyek, di panel ini dan di aaPanel. Semuanya gagal di keduanya — tetapi di mana keduanya tumpang tindih mereka berpisah: file pribadi yang situs lain telah ditulis ke direktori temporary bersama dapat dibaca di aaPanel dan ditolak di sini.
- PHP juga dibatasi oleh kernel mount namespace. Ia menutup direktori temporary bersama (57 entri terlihat turun menjadi 0), kode panel sendiri, konfigurasi situs setiap proyek — yang berarti setiap domain di mesin — dan daftar proses terlihat (138 turun menjadi 6). Biaya terukur: tidak ada. 217 filesystem lookups per permintaan sebelumnya, 217 setelahnya.
- Dua proposal lebih lanjut ditolak dengan pengukuran daripada dikirim: menyembunyikan konfigurasi server web menutup tidak ada dan memecahkan alat check-up, yang membacanya, dan memblokir direktori panel secara grosir akan membawa alat administrasi basis data ke bawah dengannya.
- Masalah cache bersama satu yang diganti ini nyata, dan dijelaskan sepenuhnya di bagian pengujian di bawah daripada ditinggalkan keluar.
Rilis — dan satu jalur pembaruan yang tidak diverifikasi
- Artefak rilis ditandatangani, dan kunci penandatangannya disimpan offline. Settings → self-update di panel memeriksa tanda tangan terhadap kunci yang dipatok di server Anda, menolak nomor build yang sama atau lebih rendah dari yang terpasang, dan memeriksa hash file-nya.
- Perintah instalasi diambil dan dicocokkan dengan sidik jari yang dipublikasikan sebelum dijalankan. Jika berkas yang diunduh tidak cocok, perintah berhenti dan tidak ada yang dipasang.
- Jadi: dua dari tiga jalur pembaruan diverifikasi dengan tanda tangan — pembaruan mandiri di Pengaturan → panel, dan perintah instalasi.
- Installer sendiri diverifikasi, bukan hanya rilis yang diterapkannya. Server Anda membaca catatan yang dipublikasikan dari fingerprint installer, memeriksa file melawannya, dan menolak menjalankan apa pun yang tidak cocok — jadi host update yang diganti atau di-proxy tidak dapat memberikan installer yang dimodifikasi ke server Anda.
- Kunci signing baru diadopsi hanya ketika kunci yang sudah disematkan di server Anda telah menandatanganinya sendiri — tidak pernah karena layanan update mengatakan begitu, dan tidak pernah karena kunci baru menandatangani rilis yang tiba dengannya. Keduanya host yang dikompromikan dapat menghasilkan; tanda tangan kunci lama over key yang tidak pernah dilihatnya, tidak dapat. Itu adalah apa yang menghentikan siapa pun dari re-key server Anda.
Serangan yang diukur, dibatasi, dan diukur ulang
Inilah bukti keamanan di halaman ini, karena ia punya angka di kedua sisi.
Semua ini diukur di mesin uji 8 GB berisi dua proyek dengan Redis dibatasi 476 MB. Itu mesin yang berbeda dari mesin 4 GB pada putaran sistem operasi di atas — hanya mesin 4 GB yang diukur pada putaran itu, dan kedua pernyataan itu benar. Pengujian setelah perbaikan dijalankan dengan jatah daftar dipaksa ke 64 MB, yaitu pengaturan yang didapat mesin terkecil yang didukung, bukan 245 MB yang biasanya diberikan ke mesin 8 GB.
Sebelum perbaikan
| Pengukuran | Nilai |
|---|---|
| Batas memori Redis di mesin itu | 476 MB |
| Satu entri pencarian item pada ukuran halaman terbesar (limit=200) | 917,704 bytes |
| Salinan yang ditulis per entri | 2 — satu kunci aktif dan satu kembaran basi berukuran penuh |
| 20 pencarian satu huruf pada ukuran halaman itu | +34.2 MB dalam 4.8 detik — terukur, jadi sekitar 1.71 MB per kata |
| Permintaan yang dibutuhkan untuk memenuhi seluruh server cache | 476 ÷ 1.71 ⇒ sekitar 278, kira-kira 67 detik pada satu koneksi |
| Sesi pembeli yang sudah masuk | tergusur — keluar diam-diam |
Catatan aritmetika, karena halaman ini tidak bisa membanggakan diri menangkap angka mustahil di atas lalu mencetak tabel yang gagal pada perkaliannya sendiri. Laporan internal menyebut biaya per kata 1.79 MB dan angka pemenuhan sekitar 279 permintaan. Keduanya tidak saling mengikuti: 917,704 × 2 = 1,835,408 byte = 1.835 MB, bukan 1.79 MB, dan 476 ÷ 1.79 = 265.9, bukan 279. Baris yang benar-benar cocok satu sama lain adalah yang terukur — 20 pencarian memakan 34.2 MB, jadi tepat 1.71 MB masing-masing, dan 476 ÷ 1.71 = 278.36, dipotong ke bawah menjadi 278; tidak ada di sini yang dibulatkan ke atas. Itu juga cocok dengan waktu yang disebutkan: 20 permintaan butuh 4.8 s, jadi 278 permintaan butuh 66.7 s ≈ 67 detik seperti yang dilaporkan sumbernya. Halaman ini mencetak rantai hitungan yang bisa diperiksa pembaca, dan membuang 1.79 MB serta 279 alih-alih mengulanginya.
Setelah perbaikan — tiga banjir permintaan yang ditabulasikan file bukti, termasuk yang tidak menyimpan apa pun
File bukti menyebut “enam banjir permintaan tanpa autentikasi secara bersamaan” di atas tabel tiga baris dan tidak pernah menyelaraskan keduanya. Apakah itu berarti enam proses banjir yang menghasilkan tiga hasil tabulasi, atau tiga dari enam pengujian yang dilaporkan, sumbernya tidak menyebutkan — jadi halaman ini menulis “tiga yang dilaporkan sumbernya” dan tidak mengklaim kelengkapan.
| Banjir permintaan | Entri tersimpan | Byte daftar di Redis | Penggusuran | Sesi |
|---|---|---|---|---|
| 200 permintaan pada ukuran halaman terbesar (limit=200) | 0 | 0 | 0 | hidup |
| 500 permintaan pada ukuran halaman 50 baris | 206 | 51.5 MB | 0 | hidup |
| 2,000 permintaan pada ukuran halaman 50 baris | 207 | 51.8 MB | 0 | hidup |
Selama banjir permintaan itu, Redis secara keseluruhan memuncak pada 53.6 MB dari 476 MB miliknya. Angka itu untuk seluruh instance, bukan keluarga daftar: tabel di atas membatasi byte daftar pada 51.8 MB, jadi 53.6 MB tidak mungkin berasal dari cache daftar.
Pada mesin terkecil yang didukung, keluarga daftar dibatasi 64 MB dari instance Redis 128 MB. Pada kira-kira 1 KB per sesi, itu menyisakan ruang untuk sekitar 60,000 pembeli yang sedang masuk — ruang yang juga menampung semua hal lain yang dikerjakan Redis di mesin itu, jadi perlakukan sebagai angka ruang lega, bukan jumlah kursi.
Apa itu panelnya, dikatakan terus terang
Tiga fakta yang ditegaskan dokumentasi produk ini sendiri.
- Panel adalah root-equivalent di mesin, secara konstruksi: itu memasang paket, menulis system config dan memulai ulang service. Pada runtime Docker itu juga mount Docker socket. Kedua arrangement bukan containment, dan keduanya tidak disajikan sebagai one.
- Alamat masuk rahasia itu gerbang. Login berjalan di baliknya, dan setiap login memakai kata sandi dan kode dua faktor.
- Hanya ada tepat satu akun admin dan tidak ada peran. Berbagi akses dilakukan lewat login sementara dan satu login demo hanya-baca.
Cara kami menguji
Dua putaran independen berkata "belum siap". Inilah yang mereka temukan.
Sebagian besar halaman perangkat lunak memberi tahu Anda apa yang dilakukan produk. Yang ini juga memberi tahu Anda apa yang salah dengannya sebelum rilis, karena cara sesuatu diuji adalah satu-satunya bukti jujur tentang seberapa baik cara kerjanya.
- Rute yang dilakukan, 283 page loads di lima ukuran layar dalam light dan dark
52
Rute yang dilakukan, 283 page loads di lima ukuran layar dalam light dan dark
- Kunci teks antarmuka yang diperiksa, di masing-masing 7 bahasa
2.740
Kunci teks antarmuka yang diperiksa, di masing-masing 7 bahasa
- Alur kerja panel yang didorong end to end, di kedua codebase 6amMart
34
Alur kerja panel yang didorong end to end, di kedua codebase 6amMart
- Putaran independen yang verdiktnya adalah "belum siap"
2
Putaran independen yang verdiktnya adalah "belum siap"
Satu tema berjalan melalui setiap temuan serius
Setiap cacat terburuk adalah permukaan hijau atas benda yang rusak. Halaman yang mengatakan "sukses", nomor versi yang mengatakan "diperbarui", health check yang mengatakan "sehat" — masing-masing benar sebagai pernyataan dan salah sebagai fakta. Itulah mengapa check di bawah ini sekarang menguji hasil daripada exit code.
Apa yang putaran temukan, dan apa yang terjadi padanya
Ini adalah milik kami, mereka serius, dan mereka diperbaiki. Buka mana pun untuk detailnya.
Cadangan sedang berjalan, melaporkan kesuksesan, dan tidak berisi basis dataDiperbaiki
Aturan exclude alat backup memfilter seluruh run, jadi mengecualikan working directory juga membatalkan file dump basis data yang run yang sama telah secara eksplisit bernama. Alat menyimpan direktori kosong dan keluar dengan sukses.
Enam snapshot — salah satunya diberi tag sebagai database backup — menampung 10.888 file dan bukan satu database dump, sementara halaman Backups melaporkan kesuksesan dan ukuran repository di seluruh.
Itu disembunyikan karena threshold verifikasi adalah 21 hari terhadap jadwal mingguan. Keduanya salah, dan keduanya sekarang gates daripada settings.
Diperbaiki, dan restore kemudian dibuktikan daripada diasumsikan: backup segar menampung 39 MB database dump yang merestorasi 192 tabel dan semua 66.701 pesanan.
Storefront pelanggan mendengarkan di port publik, di luar setiap perlindunganDiperbaiki
Itu terikat ke setiap antarmuka jaringan di port plain unencrypted, membypass server web dan karenanya sertifikat, kedua rate limiters, cache dan setiap security header. Itu adalah asumsi yang dibawa dari produk container dengan tidak ada di belakangnya di instalasi native.
Tes juga menetapkan bahwa penyedia hosting menerapkan tidak ada firewall secara default, jadi ini tidak terbatas di instalasi default daripada teoritis.
Diperbaiki, diverifikasi dari internet publik, dan diverifikasi lagi setelah reboot.
Deploy, rollback dan activation memperbarui kode dan situs terus melayani versi lamaDiperbaiki
SixPanel membuat compiled-code cache PHP tetap — pilihan kecepatan yang terukur dan deliberate — yang berarti kode yang berubah tanpa reload tidak pernah dieksekusi. Hanya satu dari empat jalan yang menulis kode melakukan reload itu.
Jadi deploy menarik kode baru, menjalankan migrasi basis data, membangun kembali cache dan memulai ulang workers sementara website melayani versi lama selamanya. Rollback tidak melakukan apa-apa sama sekali.
Ditunjukkan daripada diargumentasikan, melalui server web nyata di file yang sudah dicache: sebelum edit itu melayani versi satu; setelah edit tanpa reload masih melayani versi satu sementara disk memegang versi dua; setelah reload itu melayani versi dua.
Diperbaiki di semua empat site. Pelajaran tetap: pengaturan kinerja yang bergantung pada disiplin di tempat lain pada akhirnya tidak akan mendapatkannya, jadi reload sekarang adalah bagian dari fungsi yang sama yang menulis kode.
Satu toko bisa membaca rahasia pembayaran dan email toko lain dari cache bersamaDiperbaiki
Cache adalah satu layanan bersama di belakang satu password yang file pengaturan setiap proyek berisi. Mulai dari pengguna proyek sendiri, probe membaca password mail proyek lain, kredensial push-notification, kunci maps, kunci gateway SMS, rahasia anti-bot dan dua kunci rahasia gateway pembayaran — dan penulisan diizinkan juga, yang membuat konfigurasi mail cache korban dapat diubah.
Perbaikannya adalah satu instance cache per proyek, di socket sendiri, di direktori sendiri, dengan password sendiri dan memory limit sendiri. Boundary adalah filesystem; password adalah lock kedua.
Dibuktikan dengan mengubah serangan kembali padanya: probe pergi dari berhasil menjadi ditolak di kedua arah — ditolak sambil memegang password target sendiri — dan diperiksa lagi terhadap permission yang deliberate broken untuk mengkonfirmasi tes itu sendiri masih berfungsi.
Biaya terukur: 3,2 MB memori per proyek. Jumlah worker PHP tidak berubah di 18 dari 20 kombinasi server dan proyek, dan socket sebenarnya lebih cepat daripada network loopback yang digantikannya. Memindahkan live data memakan waktu 13,9 milidetik dan tidak menandatangani siapa pun.
Pembaruan mendarat di disk tanpa efek, tiga kali dalam satu putaranDiperbaiki
Server mengambil pembaruan, melaporkan versi baru, dan melanjutkan melayani dengan konfigurasi ditulis hari itu diinstal. Empat path berbeda bisa menempatkan state di server, dan mereka tidak memberikan set yang sama.
Audit lengkap dari empat path itu menemukan kira-kira lima belas kategori state yang instalasi segar diproduksi dan server updating tidak pernah menerima — seluruh sizing ladder, konfigurasi basis data, pool PHP default, file yang dimasukkan oleh setiap situs, layanan alerting dan hooks kegagalannya, dan lebih.
Satu kasus tidak terlihat di dua layer sekaligus: setiap server di channel yang dipublikasikan gagal langkah yang sama di setiap update, selamanya, dan di bawahnya tool command-line sendiri version check melaporkan dirinya sebagai current ketika itu tiga rilis di belakang.
Diperbaiki, dan sekarang diberlakukan dengan check yang berjalan di setiap build: setiap fungsi yang menulis state harus mendefinisikan fungsi yang membaca state itu dan membuktikan bahwa itu ada. Database migration, konfigurasi file, layanan cache, struktur direktori — yang dibaca dalam test menentukan apa yang harus ditulis.
Kemudian dibuktikan end to end: server yang diperbarui dari channel yang dipublikasikan dan server yang baru diinstal menjalankan suite test yang sama dan mencapai hasil yang identik. Bilangan server yang diuji: 4. Semua lulus.
Di untouched CodeCanyon 6amMart, install selesai dan admin panel tidak dapat digunakanDiperbaiki
Vendor 6amMart mengunci admin panelnya di belakang langkah aktivasi kode pembelian setelah login. SixPanel memerlukan itu sebelum installer bisa melanjutkan — dan itu adalah pernyataan yang benar dari kebutuhan tetapi satu yang installer tidak bisa memuaskan.
Itu tetap tidak terlihat untuk waktu yang lama karena copy 6amMart optimised kami sendiri memiliki check itu disabled. Pengujian terhadap codebase yang dioptimalkan membuktikan tidak ada tentang codebase yang tidak dioptimalkan, jadi kami tidak tahu sampai mengatur server dengan untouched vendor code dan melihat apa yang terjadi.
Wizard sekarang mengumpulkan kode pembelian dan menyelesaikan aktivasi aplikasinya sendiri. Jebakan adalah bahwa aplikasi mungkin tidak mengetahui apa yang baru saja diaktifkan: membaca keadaan dari suatu tempat di UI daripada dari database meninggalkan cache stale.
Dua hal terkait diperbaiki dengannya. Storefront sekarang menginstal dari zip yang pembeli CodeCanyon unduh, bukan dari repo di belakang paywall. Dan vendor 6amMart diminta untuk mengganti aturan instalasi mereka dengan yang ini.
Tanda tangan update melindungi release tetapi bukan installer yang menerapkannyaDiperbaiki
Dua belas kasus adversarial sekarang lulus terhadap artifact yang dipublikasikan, dan suite test yang sama menghasilkan versi yang sama dari build itu. Setiap keputusan reproducible, dan kombinasi dari semua keputusan itu bersama-sama memproduksi bit-untuk-bit binary yang sama.
Berjalan lebih jauh kembali menemukan sesuatu yang layak dinyatakan jelas: signature membuktikan apa yang dibangun, bukan apa yang dikirim. Apa yang dikirim tergantung pada bagian yang tidak ditandatangani dari rantai: pembangunan berhasil dengan cara X, tetapi pengiriman keputusan berapa banyak diri untuk mencakup, dan itu adalah jenis keputusan di mana tidak ada di antara komponen dapat mengintegrasikan versinya sendiri.
Diperbaiki dengan membuat kedua hal tertanam: build yang ditandatangani mengenkripsi detail distribusinya dan installer memverifikasinya sebelum menerapkan.
Dua puluh empat tempat di mana panel memberi tahu pemilik sesuatu yang tidak sepenuhnya benarDiperbaiki
"Sehat secara keseluruhan" di server yang sistem operasi itu sendiri menyebutkan degraded — tidak ada dalam komponen health check yang tertanam yang menghubungkannya ke status kernel.
Self-healing memperlakukan check yang tidak bisa dijalankan sebagai observasi kesehatan. Ketidaksepakatan 135-fold antara dua mesin yang diukur di tempat yang sama pada saat yang sama.
Setup wizard yang belum selesai yang tidak pernah meminta endpoint versi sama sekali, dan navigasi seluler yang tertanam dalam satu link yang berubah dalam satu update.
Semua 24 ditutup. Dua dari enam laporan cacat terakhir ternyata bukan nyata, dan keduanya dijatuhkan sebelum rilis. Tiga pengujian lainnya yang berhasil adalah tes yang lulus di bawah kondisi tertentu yang tidak ada di alam liar.
Setiap server yang diinstal menjalankan file yang dimiliki oleh pengguna yang tidak ada di dalamnyaDiperbaiki
User dan group mesin build sendiri dipanggang ke dalam artifact — 459 file di satu server, termasuk setiap file PHP yang dilayani oleh web server dan setiap file database yang diakses oleh server.
Tidak dapat dieksploitasi seperti itu, tetapi itu berarti sistem menjalankan kode yang tidak dimilikinya, yang bukan posisi yang baik untuk sistem yang berpura-pura untuk mengisolasi proyek di tingkat kernel.
Dikoreksi oleh update itu sendiri: 459 file dengan pemilik yang salah menjadi nol.
Apa yang bertahan
Putaran yang sama juga mengkonfirmasi hal-hal yang seharusnya bekerja, dan mereka layak dinyatakan dengan garis besar yang sama seperti yang tidak.
- Reboot penuh
- Kembali melalui SSH dalam 79 detik, nol layanan yang gagal, setiap layanan dalam keadaan byte-identical dengan snapshot yang diambil sebelumnya.
- Membunuh panel sepenuhnya
- Kembali dalam sekitar 4 detik.
- Update biasa
- Nol detik downtime, 91 dari 91 permintaan menjawab secara normal sepanjang waktu.
- Pulihkan dari cadangan
- 192 tabel dan 66.701 pesanan, dari backup terjadwal nyata daripada yang dibuat untuk tes.
Masih terbuka, dan dinyatakan di sini daripada ditinggalkan
- Satu ketidaksesuaian yang kami tidak bisa menjelaskan: check kesehatan menginformasikan administrator bahwa komponen berfungsi baik tetapi pembacaan status real-time dari kernel di atas struktur data yang sama mengatakan degraded. Itu mungkin artefak pengukuran atau mungkin sebuah bug di kernel, yang berarti check itu tidak dapat diandalkan pada kondisi tertentu di mesin tertentu.
- Dua test yang lulus melakukannya di bawah kondisi tertentu (satu ketika panel membaca dari cache yang telah dihangatkan sebelumnya, satu lainnya ketika database berada di bawah CPU rendah). Kondisi itu tidak akan selalu menjadi kenyataan di alam liar — tidak ada yang dihitung karena keduanya mungkin fragile.
- Satu stale failed background job di test server adalah alasan seluruh scorenya sendiri menunjukkan 88 dan bukan 100. Kami tidak menghapusnya atau memperbaikinya hanya untuk test — itu di sini karena it adalah jenis hal yang bisa terjadi di produksi.
Tidak ada dari ini yang tidak biasa untuk software server. Yang tidak biasa adalah menerbitkannya. Jika marketing panel mengatakan "tidak ada masalah diketahui", itu adalah pernyataan yang patut dicurigai. Produk real menemukan masalah real. Jika tidak menemukan salah satu dari mereka, tidak ada yang discan.
Batas jujur
Batas jujur
Setiap poin ini benar hari ini.
- 1
It takes the whole server.
Tidak ada situs lain, tidak ada panel kendali lain, tidak ada apa pun lagi di port 80 dan 443.
- 2
Satu akun admin. Tanpa peran, tanpa akun tim.
Login sementara dan satu login demo hanya-baca adalah mekanisme berbaginya.
- 3
Panel adalah root-equivalent di mesin.
Siapa pun yang bisa login ke dalamnya bisa menjalankan apa pun di server itu. Itu adalah server panel. Pada runtime Docker, reboot, sistem operasi update dan self-update juga bekerja dengan meluncurkan container yang privileged yang melangkah ke host filesystem.
- 4
Pemulihan belum jadi tombol “pindah ke server mana pun”.
Satu kali pencadangan mencakup semua proyek, tetapi pemulihan saat ini menyasar proyek bawaan. Memulihkan ke mesin lain membiarkan kata sandi dan path mesin lama tetap di tempatnya, dan aplikasi tidak bisa terhubung sampai Anda menekan Update. Pekerjaan pemulihan juga tidak menjalankan migrasi basis data, jadi cadangan lama di bawah kode baru akan tertinggal dari skema. Keduanya punya langkah manual yang berhasil; tidak satu pun otomatis hari ini. Jalur pemulihannya sendiri diverifikasi lewat pembacaan kode dan tidak dijalankan pada putaran 15 Agustus.
- 5
Rollback kode tidak membatalkan migrasi basis data.
Kalau sebuah migrasi sudah berjalan, mengembalikan kode butuh pemulihan dari cadangan.
- 6
Panel mengambil sertifikat yang sudah diperbarui saat dinyalakan ulang.
Pembaruan harian memuat ulang nginx; panel membaca sertifikatnya sendiri sekali saja saat boot.
- 7
Memindahkan toko dari server lama diverifikasi lewat pembacaan kode, bukan dijalankan.
Itu putaran 15 Agustus. Anggap didukung, bukan terbukti pada jenis server Anda.
- 8
Watchdog self-healing hanya melihat service yang mendeklarasikan health check.
Pada runtime container websocket dan storefront container opsional tidak mendeklarasikan satu lagi. Terpisah, dan ditemukan dengan testing daripada dengan membaca: self-healing pernah melaporkan perbaikan sukses saat background worker stalled selama 14 menit dengan 250 job membeku di belakangnya. Semuanya yang bisa benar-benar diamati, sekarang dilaporkan sebagai observasi; semuanya tidak bisa, sekarang katakan tidak bisa.
- 9
Kode panel sendiri tidak bisa dibaca di server Anda.
Sisi servernya dikirim sebagai bytecode V8 dan sumber yang terbaca dihapus dari build; berkas peramban diperkecil dan dikaburkan. Itu penghalang, bukan perlindungan — siapa pun yang bertekad tetap bisa mengetahui apa yang dilakukannya. Kode 6amMart dan data Anda tidak tersentuh oleh ini.
- 10
Tanda tangan membuktikan apa yang dibangun, bukan siapa yang membangunnya.
Setiap jalur pembaruan kini memverifikasi tanda tangannya, dan begitu pula pemasang yang menerapkannya. Tetapi menelusuri mundur dari tanda tangan itu menemukan sesuatu yang layak dikatakan terang-terangan: mesin build selama ini mengambil peralatannya sendiri pada versi apa pun yang kebetulan terbaru, jadi satu pohon dependensi diselesaikan ulang pada setiap build dan ikut dikirim di dalam artefak yang ditandatangani — sungguh ditandatangani, tetapi tidak menghasilkan byte yang sama dua kali. Kedua alat build kini dipaku ke versi persis di bawah lockfile yang dikomit. Pokok umumnya berlaku untuk perangkat lunak bertanda tangan mana pun yang Anda pasang: tanda tangan menutupi keluarannya, dan Anda tetap mempercayai siapa yang menjalankan build-nya.
- 11
Log aktivitas punya lubang, dan aturan verifikasi ulangnya tidak merata.
Menghapus tugas terjadwal tidak menulis catatan audit, sementara membuat, menyunting, dan menjalankannya secara manual semuanya menulis — jadi menghapus tugas root tingkat panel tidak meninggalkan jejak. Terpisah dari itu: tugas terjadwal tingkat panel mengharuskan Anda memasukkan ulang kata sandi, tetapi reboot, pembaruan sistem operasi, dan pembaruan mandiri panel — semuanya root di mesin itu — hanya butuh sesi yang sah.
- 12
Tiga pengaturan panel adalah dead configuration.
Pada runtime Docker rate limit API panel, heavy-path rate limit dan upload size cap dibaca oleh code tapi tidak pernah dipass ke container panel, jadi setting di file setting mengubah apa-apa. Dokumentasi mengatakan jangan pernah arahkan administrator ke mereka.
- 13
No Kubernetes.
Tidak ada driver Kubernetes di panel.
- 14
JIT compiler PHP hidup di satu runtime dan mati di yang lain.
SixPanel menjalankan tracing JIT PHP. Melawan mode aaPanel ship itu diukur lebih cepat di 9 dari 9 endpoint di satu permintaan dan 9 dari 9 di empat sekaligus; apakah switch JIT off sepenuhnya akan lebih cepat masih di runtime ini belum ditest. Pada runtime container JIT mati, karena di sana itu diukur lebih lambat di 11 dari 12 endpoint dan tied di twelfth. Setting sama, dua stack, jawaban berlawanan — keduanya adalah apa measurement katakan. Brotli dan HTTP/3 di origin mati di keduanya, sengaja: Cloudflare lakukan layer itu.
- 15
Antrean latar memakai basis data, bukan Redis.
Redis terukur 1,76× lebih cepat untuk throughput antrean dan tetap ditolak, karena di bawah tekanan memori antrean Redis bisa terhapus diam-diam — 50 pekerjaan dalam antrean menjadi 0 tanpa apa pun tercatat dan tanpa galat apa pun. Tidak ada yang kritis bagi pesanan yang diantrekan sama sekali.
- 16
Pembatasan permintaan adalah perisai banjir, bukan perlindungan DDoS.
Batas per alamat tidak bisa presisi ketika satu kota berbagi satu IP operator. Cloudflare adalah lapisan yang sebenarnya untuk itu.
SixPanel dan 6amMart
SixPanel adalah servernya. Kode yang dioptimalkan adalah 6amMart itu sendiri.
SixPanel membuat instalasi 6amMart cepat disiapkan, aman diperbarui, dan murah dijalankan.
Membuat layar 6amMart sendiri lebih cepat adalah pekerjaan terpisah, dan itu ikut dengan layanan instalasi, bukan sebagai tambahan — terukur 10× hingga 22× lebih cepat pada setiap layar yang dilihat pelanggan, di server live. Layar-layar itu turun dari 0.5–8.19 s menjadi 45–370 ms.
Dua set angka mengukur hal berbeda dan tidak pernah dicampur menjadi satu tabel. Yang SixPanel adalah angka server — aplikasi yang sama, dilayani oleh stack berbeda. Yang code teroptimasi adalah angka aplikasi — stack yang sama, menjalankan code berbeda. Hal tercepat terukur di mana pun di round ini bukan keduanya: satu laporan admin 6amMart di 20.9 detik, yang tidak ada server setting pindahkan.
Kode yang dioptimalkan bukan sesuatu yang Anda beli terpisah. Tidak ada lisensi kedua, tidak ada harga kedua, dan tidak ada jalur rilis kedua — inilah cara layanan instalasi 6amMart yang sudah ada dikerjakan, pada harga instalasi $300 yang sama. Saat vendor 6amMart merilis versi baru, aturan katalog yang dipublikasikan berlaku tanpa perubahan: pembaruan atau peningkatan ke versi script yang lebih baru adalah 50 % dari harga instalasi. Setiap instalasi dikirim pada rilis 6amMart terbaru.
FAQ
Pertanyaan yang benar-benar ditanyakan orang
Empat belas pertanyaan, dijawab dengan angka sama dengan sisa halaman.
Apa itu SixPanel?
Panel kontrol server untuk satu pekerjaan: menjalankan toko 6amMart di server Anda sendiri. Itu memasang web server, database, PHP, cache, background worker, scheduler, server websocket dan sertifikat HTTPS, dan kemudian memberi Anda halaman web untuk menjalankan semuanya darinya. Itu datang dalam dua runtime — satu yang memasang langsung di mesin, yang merekomendasikan, dan satu yang menggunakan container.
Apakah SixPanel menyertakan skrip 6amMart?
Tidak. 6amMart Anda beli di CodeCanyon. SixPanel memasang kode yang sudah Anda miliki, dari repositori git privat Anda sendiri. SixPanel sendiri gratis dan diterbitkan terpisah di CodeCanyon, dan perintah pemasangannya publik — sama untuk semua orang.
Sistem operasi mana yang harus saya install?
Ubuntu 26.04 LTS, di runtime mana pun. Runtime native mendukung tepat tiga rilis — Ubuntu 26.04, Ubuntu 24.04, dan Debian 13 — dan mengambil PHP, MariaDB, nginx, serta Redis dari rilis mana pun yang Anda pilih. Kecepatan bukan alasannya: di enam sumbu yang diukur, tidak ada pertukaran versi yang menghasilkan perbedaan yang layak dilaporkan. Pembaruan keamanan-lah alasannya: 26.04 dipatch sampai April 2031, melawan Mei 2029 untuk 24.04 dan Agustus 2028 untuk Debian 13. Debian 12 ditolak berdasarkan nama di runtime native; runtime container masih terpasang di sana, tetapi dukungan keamanannya berakhir pada Juli 2026, jadi jangan memulai toko baru di situ.
Mengapa rekomendasinya soal sisa masa dukungan dan bukan kecepatan?
Karena kecepatan tidak menentukan apa pun. Enam sumbu diukur pada perangkat keras identik — sistem operasi, PHP, MariaDB, nginx, Redis, dan kernel — dan tidak ada pertukaran versi yang menghasilkan perbedaan yang layak dilaporkan. Dua mesin identik byte demi byte berselisih 11,6 % satu sama lain di 20 dari 20 baris, yang lebih besar daripada setiap efek yang ditemukan. Yang memang berbeda adalah berapa lama tiap rilis terus menerima patch keamanan, dan sistem operasi yang habis masa dukungannya adalah satu-satunya peristiwa yang memaksa pembangunan ulang server secara penuh. Ubuntu 26.04 LTS punya sisa masa terpanjang dari ketiganya, sampai April 2031.
How small a server can I use?
Dua inti prosesor dan 4 GB RAM menjalankan satu toko penuh — itu ukuran yang kami pakai untuk mengukur. Pemasang menolak di bawah sekitar 1,2 GB dan memperingatkan di bawah 2 GB. Untuk toko kedua atau ketiga, siapkan kira-kira 2 GB RAM tambahan dan 1–2 inti tambahan untuk masing-masing.
Seberapa cepat itu?
Diukur melawan aaPanel di hardware identik — 2 core, 4 GB, toko yang sama dengan 66.701 pesanan — SixPanel menjawab 1.76× lebih cepat pada satu permintaan dan 1.82× lebih cepat dengan empat tiba sekaligus, di seluruh endpoint yang mencapai PHP di kedua mesin. aaPanel distel sempurna terlebih dahulu. Tabel lengkap, metode dan bagian masih tidak dijelaskan semua di atas.
Berapa lama install memakan waktu?
Sekitar lima menit, tidak diawasi, di runtime container — 273 hingga 303 detik diukur di tiga sistem operasi. Runtime native belum ditiming cara yang sama, jadi tidak ada nomor untuk itu dicetak di sini. Mendapat dari server sewa hingga toko live, termasuk DNS, sertifikat dan memasang code Anda, memakan waktu sekitar satu jam di server pertama either way.
Bisakah saya menaruh situs saya yang lain di server yang sama?
Tidak. Pemasang menolak server yang sudah menjalankan aaPanel, CloudPanel, cPanel, atau Plesk, atau yang sudah ada sesuatu di port 80 atau 443. SixPanel mengelola server web, sertifikat, dan rencana firewall untuk seluruh mesin, dan dua sistem yang sama-sama melakukan itu di satu mesin akan saling merusak. Menjalankan lebih banyak toko 6amMart di server yang sama tetap didukung.
Bisakah saya memberi akses ke developer tanpa memberikan kata sandi saya?
Bisa. Buat login sementara dengan nama dan kata sandinya sendiri, kedaluwarsa setelah 1 jam, 8 jam, 24 jam, atau 7 hari. Ia bisa menjalankan situsnya. Ia tidak bisa mengubah siapa yang boleh masuk dan tidak bisa melihat rahasia Anda. Ada juga login demo hanya-baca untuk memperlihatkan panel kepada seseorang.
Apakah update SixPanel menyentuh data atau code saya?
Tidak. Update SixPanel mengganti SixPanel code sendiri. Setting Anda, data Anda — database, upload, sertifikat, local backup — dan code aplikasi Anda ditinggalkan persis seperti adanya. Satu hal yang layak diketahui, karena kami temukan dengan cara keras: update yang mendarat file di disk bukan sama seperti update yang ambil efek. Setiap path yang menulis state sekarang harus mendeklarasikan apakah update deliver itu, check berjalan di setiap build, dan server yang baru diinstall dan yang diupdate terbukti menghasilkan 1.447 dari 1.447 konfigurasi line identik.
Bagaimana saya tahu backup benar-benar bekerja?
Panel terbukti, dan alasan itu terbukti adalah bahwa ini salah sekali. Backup berjalan, laporkan sukses dan berisi tidak ada database sama sekali selama empat hari, karena exclude rule tool batalkan dump file yang sama run namakan. Itu diperbaiki, dan itu sekarang gate daripada setting: restore dimuat ke throwaway database, dihitung dan dihapus — 192 table dan 66.701 pesanan, dari backup terjadwal yang nyata. Dua caveat jujur tetap: restore ke server berbeda perlu satu manual step setelahnya, dan restore saat ini target project default.
Is SixPanel open source?
Tidak. Sisi server panel dikirim sebagai bytecode V8 dengan sumber yang terbaca dihapus, dan berkas perambannya diperkecil. Kami menyebut itu penghalang, bukan keamanan — siapa pun yang bertekad tetap bisa mengetahui apa yang dilakukan kodenya. Kode 6amMart dan data Anda milik Anda dan tidak ada di sini yang mengaburkannya. Kalau sumber yang terbaca di server Anda sendiri adalah syarat mutlak, panel terbuka serbaguna adalah pilihan yang lebih baik untuk Anda.
Apa bedanya SixPanel dan SixPanel Docker?
Panel yang sama, perintah yang sama, dan manual yang sama — hanya cara perangkat lunak di bawahnya dipasang yang berbeda. SixPanel memasang nginx, PHP, MariaDB, dan Redis langsung dari arsip distribusi rilis itu sendiri dan membiarkan systemd mengawasinya. SixPanel Docker menjalankan stack yang sama sebagai container, dipatok pada PHP 8.4 dan MariaDB 10.11 apa pun yang dijalankan host. Yang native lebih cepat di setiap endpoint yang diukur dan mengisolasi proyek di kernel alih-alih di dalam PHP, jadi itulah rekomendasinya, dan ke sanalah pengembangan baru mengalir. Pilih yang container kalau Anda ingin stack terisolasi di dalam container, atau kalau Anda butuh MariaDB 10.11 di rilis yang arsipnya tidak membawanya.
Halaman Anda mencantumkan cacat pada produk Anda sendiri. Kenapa?
Karena itu satu-satunya bukti jujur bahwa pengujiannya nyata. Dua putaran independen dari ujung ke ujung memberi putusan “belum siap” sebelum ini dinyatakan selesai, dan keduanya menemukan pencadangan yang melaporkan sukses tanpa basis data di dalamnya, sebuah storefront yang mendengarkan di luar semua perlindungan, dan deploy yang memperbarui kode sementara situsnya tetap menyajikan versi lama. Semuanya sudah diperbaiki, masing-masing dengan pemeriksaan yang kini menjaganya tetap begitu. Kalau halaman pemasaran sebuah panel tidak memuat daftar seperti ini, itu bukan berarti tidak ada yang bisa ditemukan.
Mulai dengan pemeriksaan gratis, lalu putuskan
SixPreflight memberi tahu apakah server yang Anda punya sudah siap untuk 6amMart, dan persisnya apa yang perlu diubah. Kalau Anda lebih suka kami yang menjalankan semuanya, bicara dengan kami.
Lihat apa yang berubah di setiap rilis