6amMart yang dioptimalkan: script yang sama, diukur dan diperbaiki
AllsWeb menginstal rilis 6amMart terbaru — script yang sama, admin yang sama, aplikasi yang sama — di atas kode yang sudah kami ukur dan perbaiki. Layar yang dilihat pelanggan berjalan 10× hingga 22× lebih cepat daripada versi bawaan, 342 cacat sudah ditutup, dan rangkaian uji yang ikut dikirim bersama build membuktikannya.
Kode yang dioptimalkan sudah termasuk dalam harga instalasi. Ini bukan upgrade, bukan add-on, dan bukan paket tingkat lain.
10× – 22×
lebih cepat pada layar yang dilihat pelanggan
342
cacat ditemukan dan diperbaiki
799
commit di lima repositori
1–3 hari
pengiriman setelah kebutuhan Anda lengkap
Membaca halaman ini dengan asisten AI?
Dengan ini versus tanpa ini
Apa yang berubah di hari toko Anda buka
6amMart bawaan di kiri, kode yang dipasang AllsWeb di kanan. Script yang sama, panel admin yang sama, aplikasi yang sama, rilis vendor yang sama — setiap angka diukur di server 4 GB, 2 inti yang sama, dengan data yang sama.
Layar pertama yang dilihat pembeli
Bawaan
Baris unggulan di layar utama butuh 8,19 detik untuk terisi. Cukup lama bagi pembeli di ponsel untuk menyimpulkan aplikasinya rusak lalu menutupnya.
Dioptimalkan
Baris yang sama terisi dalam 0,37 detik — 22× lebih cepat, diukur dengan CDN dilewati agar yang diukur adalah aplikasinya, bukan cache.
Laporan pendapatan toko
Bawaan
Menggambar satu laporan mengajukan 8.614 pertanyaan terpisah ke basis data, dan menahan satu koneksi terbuka selama itu. Beberapa admin membukanya bersamaan sudah cukup membuat seluruh toko terasa berat bagi semua orang.
Dioptimalkan
Laporan yang sama mengajukan 12 pertanyaan. Sebelumnya terlihat wajar saat diuji, karena pada data kecil masing-masing dari 8.614 pertanyaan itu cepat.
Belanja minimum sebuah kupon
Bawaan
Panel admin mengizinkan Anda mengaturnya dan kodenya tidak pernah membacanya. Dibuktikan langsung: kupon dengan minimum ₹999 diterima pada pesanan ₹1, dan ada enam kupon aktif yang disetel seperti itu.
Dioptimalkan
Kini ditegakkan di ketiga tempat harga sebuah pesanan dapat dihitung.
Diskon sore hari
Bawaan
Basis data berjalan pada UTC dan aplikasi pada waktu India — terukur selisih 5 jam 30 menit pada instalasi nyata. Diskon sore 18:00–22:00 karena itu tidak pernah berlaku pada sore hari dan justru menyala pukul 2 pagi. Layar daftar dan checkout memakai jam yang berbeda, sehingga sebuah toko bisa diiklankan berdiskon lalu menagih harga penuh.
Dioptimalkan
Satu jam saja, jadi diskon yang ditampilkan adalah diskon yang ditagih.
Siapa yang bisa membaca pesanan seorang pelanggan
Bawaan
Lebih dari enam endpoint menerima ID pesanan apa pun dengan ID tamu hasil terkaan. Direproduksi tanpa autentikasi sama sekali: responsnya memuat item, harga, dan alamat pengiriman pelanggan lain. Endpoint pembayaran dompet di jalur yang sama juga tidak memeriksa saldo.
Dioptimalkan
Cakupan kepemilikan pada setiap endpoint terdampak, sementara checkout tamu yang sah tetap berfungsi.
Gateway pembayaran yang Anda matikan
Bawaan
Mematikannya di panel admin hanya menghapusnya dari pilihan pelanggan. URL callback-nya tetap hidup, dan banyak callback gateway menandai pesanan sebagai dibayar hanya berdasarkan satu kata status di URL — jadi dengan semua gateway dimatikan, sebuah callback tetap berhasil dan pelanggan bisa mengonfirmasi pesanannya sendiri tanpa membayar.
Dioptimalkan
Kini gagal dalam keadaan tertutup, dengan 102 uji pada setiap prefiks gateway memastikan tidak ada yang berjalan saat nonaktif.
Apa biayanya bagi Anda
Bawaan
6amMart bawaan adalah apa yang diberikan instalasi biasa.
Dioptimalkan
Instalasi yang sama, pada rilis 6amMart terbaru. Tanpa lisensi kedua, tanpa harga kedua, tanpa tingkat peningkatan — ini memang cara instalasinya dikirim.
Arti “dioptimalkan” di sini
6amMart yang sama. Berbeda di dalamnya.
Ini 6amMart yang sama — rilis terbaru, apa pun yang sedang dikirim 6amTech pada hari kami membangun instalasi Anda. Panel admin yang sama, panel vendor yang sama, aplikasi pelanggan, toko, dan kurir yang sama, model data yang sama, fitur yang sama seperti yang Anda lihat di demo. Tidak ada yang diganti dan tidak ada yang diganti namanya. Yang berubah ada di dalamnya: AllsWeb memakai empat belas sesi kerja untuk mengukur script ini, membuat profilnya, dan memperbaiki apa yang ditemukan pengukuran — 799 commit di lima repositori antara 13 Juli dan 9 Agustus 2026, pada backend, panel admin, situs web, dan tiga aplikasi. Setiap perubahan itu harus mengembalikan data yang identik byte per byte sebelum diterima. Ini bukan produk lain yang harus Anda pilih. Ini cara kami menginstal 6amMart sekarang.
Apa yang Anda beli
- Layanannya tidak berubah
- Instalasi, penyiapan, dan konfigurasi lengkap 6amMart di hosting Anda — panel admin, panel vendor, Android APK + AAB, build iOS, situs web pelanggan, branding Anda, SMTP, Maps, Firebase push dan OTP, login sosial, gateway pembayaran Anda, file bahasa Anda, serta source yang sudah dikustomisasi di repositori GitHub privat.
- Pengiriman
- 1–3 hari kerja setelah kebutuhan Anda lengkap.
- Dukungan seumur hidup gratis
- Untuk masalah penyiapan dan perbaikan kecil.
- Lisensi CodeCanyon milik Anda sendiri
- Anda membeli dan memiliki lisensi 6amMart Anda sendiri dari CodeCanyon; kami memasang di atasnya.
Kode yang dioptimalkan sudah termasuk dalam harga instalasi. Ini bukan upgrade, bukan add-on, dan bukan paket tingkat lain.
Kenapa versi bawaan lambat
Satu kalimat, dan satu temuan
Databasenya tidak lambat. Aplikasinyalah yang menanyakan pertanyaan yang sama ratusan kali per halaman.
Bagian yang belum dilihat kebanyakan orang
Pada satu endpoint pelanggan, satu permintaan menjalankan 112 kueri database. Delapan puluh enam di antaranya — 76% — dijalankan saat mengubah hasil akhir menjadi JSON untuk dikirim, karena accessor atribut mengambil data secara lazy, satu kali per baris, pada saat serialisasi. Tujuh mengambil datanya dan sebelas menyiapkannya. Itulah sebabnya menambah indeks saja tidak akan mengubah apa pun: biayanya tidak ada pada kueri yang dijalankan halaman itu.
Endpoint itu kini menjalankan 45.
86 ÷ 112 = 76.8%, ditulis 76%. Sumbernya menulis 77%; sumber yang membulatkan ke atas tidak memberi hak halaman ini untuk ikut membulatkan ke atas.
Perbandingan hasil pengukuran
Sebelum dan sesudah, di server yang sama
Pernyataan metode
| Kondisi | Apa isinya |
|---|---|
| Sebelum | Script bawaan persis seperti yang dikirim CodeCanyon pada saat eksperimen — commit dasar d92ce004, 8 Juli 2026 ‡ |
| Sesudah | Script yang sama setelah program optimasi dan pengamanan AllsWeb, dengan rilis berikutnya dari vendor ditumpangkan sesudahnya |
| Server | Mesin yang sama untuk kedua pengukuran — 2 vCPU, 3.9 GB RAM |
| Metode | Diukur di sisi server, dengan CDN dilewati |
| Skala perubahan | 799 commit · 342 perbaikan · 171 perubahan kecepatan · 37 fitur |
| Aturan penerimaan | Setiap perubahan performa harus mengembalikan data yang identik byte per byte sebelum diterima |
- ‡ Apa yang diukur. Angka “sebelum” diambil dari script bawaan seperti yang dikirim CodeCanyon pada 8 Juli 2026 — rilis yang diberi nomor 4.0.1 oleh 6amTech — dan rilis berikutnya dari vendor ditumpangkan ke kode yang dioptimalkan sesudahnya. Itu pernyataan tentang eksperimennya, supaya angka “sebelum” bisa direproduksi dari titik awal yang sama. Itu bukan pernyataan tentang apa yang Anda terima: kami memasang rilis apa pun yang sedang dikirim 6amTech pada hari kami membangunnya. Pekerjaan besar berikutnya masuk pada 13–15 Agustus 2026 dan tidak tercakup dalam laporan 9 Agustus.
- Aturan penerimaan, dalam satu baris. “Lebih cepat tidak pernah boleh berarti berbeda.”
- Pembulatan yang merugikan kami. Jika nilai yang diukur berupa rentang, kelipatan di sini dihitung dengan cara paling tidak menguntungkan yang dimungkinkan angkanya — nilai “sebelum” terendah dibagi nilai “sesudah” tertinggi. Laporan kami sendiri mengutip kelipatan titik tengah, yang hasilnya lebih tinggi.
Sembilan baris, semuanya sebelum/sesudah, dan tidak semuanya jenis pengukuran yang sama, jadi tabelnya menyebutkan yang mana. Baris 1–5 adalah waktu respons yang diambil di server yang sama dengan CDN dilewati. Baris 6–7 adalah jumlah pertanyaan database per halaman, di mana “CDN dilewati” bukan kondisi yang berarti. Baris 8–9 sama sekali bukan pengukuran server dan diberi tanda †. Ini baris-baris yang benar-benar dirasakan pemilik toko, bukan angka terbesar yang kami punya.
| # | Apa itu | 6amMart bawaan | Dioptimalkan | Kelipatan |
|---|---|---|---|---|
| 1 | Item unggulan di layar beranda | 8.19 s | 0.37 s | 22× lebih cepat |
| 2 | Pencarian produk | 1.64 – 1.96 s | 0.09 – 0.12 s | minimal 13× lebih cepat |
| 3 | Halaman beranda toko | ~1.47 s | 0.073 – 0.096 s | minimal 15× lebih cepat |
| 4 | Kategori teratas | 3.34 s | 0.27 s | 12× lebih cepat |
| 5 | Konfigurasi aplikasi saat dibuka | 0.53 – 1.15 s | 0.045 s | minimal 11× lebih cepat |
| 6 | Ekspor pendapatan toko — pertanyaan database per halaman | 8,614 | 12 | 717× lebih sedikit |
| 7 | Daftar katalog produk — pertanyaan database per halaman | 557 | 92 | ~6× lebih sedikit |
| 8 | † Styling yang dikirim di setiap halaman situs — hitungan byte hasil build, bukan waktu server | 921,603 bytes | 12,386 bytes | −98.6% (74× lebih kecil) |
| 9 | † Sepuluh permintaan aplikasi berurutan — diukur dari ponsel lewat data seluler, bukan di server | 6,140 ms | 1,876 ms | −69% (3.2× lebih cepat) |
† Baris 8 dan 9 bukan pengukuran server. Kerangka “server yang sama, CDN dilewati” hanya berlaku untuk waktu respons pada baris 1–5; angka styling adalah keluaran build dan angka sepuluh permintaan diambil lewat data seluler.
Perhitungannya, dicetak terbuka
Baris 6 menulis 717×, bukan 718× seperti di laporan kami sendiri: 8,614 ÷ 12 = 717.83, dan halaman ini tidak membulatkan angka ke atas demi keuntungannya sendiri. Baris 9 menulis 3.2× dengan alasan yang sama — 6,140 ÷ 1,876 = 3.27. Hitungan byte pada baris 8 adalah 921,603 ÷ 12,386 = 74.4, ditulis 74×. Angka 76% di atas adalah 86 ÷ 112 = 76.8%, dibulatkan ke arah yang sama.
Kapasitas serentak, dinyatakan hanya sejauh yang diizinkan buktinya
Di server 2 vCPU yang sama, dalam uji beban bertahap terhadap endpoint daftar toko, 13× lebih banyak pelanggan bisa memakainya sekaligus di server yang sama. Pasangan angka permintaan-per-detik sengaja tidak dicetak: sumbernya mencatat uji beban itu tanpa menyebutkan tingkat konkurensi maupun durasinya, dan angka permintaan-per-detik yang tidak bisa menyebut endpoint, konkurensi, dan durasinya tidak layak masuk halaman ini. Angka SixPanel di bawah punya ketiganya, itulah sebabnya angka itu dicetak sebagai laju.
Dua baris yang bukan cerita kecepatan
| Apa itu | 6amMart bawaan | Dioptimalkan |
|---|---|---|
| Endpoint yang mengembalikan error server pada instalasi bersih | 3 (toko populer, toko terbaru, metode pembayaran) | 0 — ketiganya kini menjawab dalam 41–150 ms |
| Advisory keamanan dependensi yang diketahui, dihitung 9 Agustus 2026 | 111 | 0 |
Apa sebenarnya 111 itu. 110 di antaranya adalah versi axios dan vite di dalam lima file package.json modul addon yang pipeline build-nya tidak pernah berfungsi — empat menunjuk ke file sumber yang tidak ada di modul itu, dan yang kelima menunjuk ke dua file berukuran nol byte. Semuanya tetap diangkat, karena peringatan yang sudah Anda putuskan untuk diabaikan adalah peringatan yang berhenti Anda baca. Yang penting berdiri sendiri adalah firebase/php-jwt di bawah 7.0.0 (CVE-2025-45769), sebelumnya dicatat tidak bisa diperbaiki, kini di ^7.0.2 dan diverifikasi dengan kunci Apple, Passport, Firebase, dan Google yang asli.
Baris advisory adalah potret dengan tanggal padanya, dan itu ada alasannya: umpan advisory bergerak terus, dan hitungan yang diambil pada 9 Agustus 2026 adalah pernyataan tentang hari itu, bukan sifat tetap dari build ini. Jalankan ulang audit di instalasi Anda sendiri untuk angka terkini.
Keadaan saat ini, lengkap dengan syaratnya Penyapuan 306 permintaan endpoint melaporkan nol error server dan nol endpoint di atas 250 ms — diukur atas permintaan yang benar-benar dijalankan. Dalam pengujian yang sah, pembatas laju platform sendiri menolak 66–68 di antaranya, kira-kira seperlima dari penyapuan, dan permintaan yang ditolak bukan hasil endpoint. Pembagian yang tercatat pada pengujian sah (~235 berhasil, 66–68 ditolak) berjumlah sekitar 302, bukan 306; kami tidak bisa merekonsiliasi sisa permintaannya dari sumber yang kami punya. Jalankan sendiri dan baca pembagian Anda sendiri — bagian verifikasi di bawah menjelaskan caranya.
Akar penyebab
Tiga penyebab yang layak disebut
Merekalah yang membuat tabel itu masuk akal.
Ekspor pendapatan meminta hal yang salah sebanyak 2,867 kali.
Kodenya menyuruh database mengambil toko setiap transaksi lewat pesanan, sementara kodenya membaca toko langsung dari transaksi — tautan yang berbeda. Perintah itu tidak pernah berlaku, jadi semua 2,867 baris mengambil tokonya masing-masing secara terpisah.
Setiap halaman vendor menggambar dua menu navigasi.
Satu disembunyikan oleh stylesheet, keduanya menghitung badge pesanan yang sama.
Header halaman memuat seluruh riwayat pesanan toko.
466 pesanan untuk toko tersibuk, untuk mengisi bagian halaman yang sebenarnya sudah dinonaktifkan sebagai komentar.
Dan temuan soal indeks
Sepuluh kolom yang dipakai database untuk join sama sekali tidak punya indeks. Setelah diindeks, satu pencarian berubah dari membaca 51,074 baris menjadi membaca satu baris.
Daftar pelanggan di admin memeriksa 16,092,496,536 baris untuk mengembalikan 98 — 82% dari seluruh waktu kueri lambat di server, dan sampai 18 menit untuk sekali memuat halaman.
Apa yang diperbaiki
Performa, keamanan, kebenaran
Performa
Pertanyaan database per satu permintaan — setiap perubahan diverifikasi identik byte per byte sebelum diterima.
API pelanggan
| Operasi | Bawaan | Dioptimalkan |
|---|---|---|
| Daftar katalog produk (31 item) | 557 | 92 |
| Daftar pesanan vendor (41 pesanan) | 212 | 12 |
| Format detail pesanan (40 baris) | 121 | 4 |
| Riwayat pesanan pelanggan | 166 | 97 |
| Wishlist (6 item) | 140 | 37 |
| Daftar toko | 78 | 39 |
| Konfigurasi aplikasi | 54 | 21 |
| Daftar kategori | 43 | 16 |
Panel admin dan vendor
| Layar | Bawaan | Dioptimalkan |
|---|---|---|
| Ekspor pendapatan toko | 8,614 | 12 |
| Pencarian pesanan di admin | 259 | 14 |
| Pemilih produk flash sale | 186 | 42 |
| Galeri produk | 166 | 48 |
| Daftar penyedia sewa | 159 | 9 |
| Dropdown toko di Reels | 127 | 62 |
| Halaman detail pelanggan | 106 | 34 |
| Daftar kendaraan sewa | 94 | 13 |
| Halaman pendapatan toko | 89 | 13 |
| Setiap halaman vendor, sebelum isinya sendiri | 61 | 52 |
Panel admin dan panel vendor belum pernah diukur — pemeriksaan otomatis bawaan 6amMart hanya mencakup API pelanggan. 586 halaman admin dan 165 halaman vendor diprofilkan, dihitung dalam jumlah pertanyaan database “karena hitungan itu pasti dan bisa diulang, sementara stopwatch di server bersama akan bergeser”.
Situs web
- Dari 921,603 byte styling di setiap halaman, 902 KB adalah tiga pustaka ikon lengkap — 21,459 definisi ikon dikirim supaya situs bisa menampilkan 89 ikon. Build kini hanya mengeluarkan ikon yang benar-benar dipakai, dan total styling per halaman menjadi 12,386 byte, −98.6%.
- JavaScript bersama 429 kB → 269 kB (−37%).
- Halaman landing hanyalah cangkang kosong sampai JavaScript termuat; kini halaman itu mengirim 273,110 byte yang dirender oleh server.
- Permintaan konfigurasi: satu per tampilan halaman per pengunjung → satu per menit per bahasa.
- Pustaka Maps dikirim ke 9 halaman yang tidak menampilkan peta sama sekali.
- Format tanggal per baris: 8.45 µs → 0.39 µs (21× lebih murah).
- Seluruh 50 rute situs web membaik atau bertahan; tidak ada yang membengkak.
Aplikasi mobile
- Setiap permintaan membuka koneksi aman yang benar-benar baru alih-alih memakai ulang yang ada — kira-kira 426 ms per permintaan di data seluler. Sepuluh permintaan berurutan: 6,140 ms → 1,876 ms.
- Layar beranda: ~30 permintaan per pembukaan → 1 permintaan yang mencakup 14 bagian.
- Foto 1000×1000 didekode di balik avatar berukuran 40 piksel; gambar kini didekode pada ukuran yang benar-benar ditampilkan.
- 309 pernyataan logging debug ikut terkirim di dalam aplikasi yang dirilis. Sekarang nol.
- GPS kurir: 360 → ~30 laporan posisi per jam saat tidak bergerak.
- Layar pesanan vendor menggambar ulang semuanya setiap 10 detik; kini hanya menggambar ulang saat datanya berubah.
Keamanan — lubang spesifik yang ditemukan pada script seperti yang dijual
Tidak ada satu pun di bagian ini yang sekadar preferensi. Masing-masing adalah cacat yang ada di 6amMart bawaan, dan masing-masing direproduksi sebelum diperbaiki.
SQL injection tanpa autentikasi yang bisa dicapai dari setiap daftar toko.
Kode daftar toko memasukkan header permintaan latitude dan longitude mentah langsung ke perhitungan jarak SQL. Bisa dicapai tanpa login dan tanpa token. Dipastikan sampai ke database — payload yang disuntikkan menghasilkan error sintaks database di log langsung. Diperbaiki dengan parameter terikat; satu titik injeksi kedua yang tidak terpakai dihapus.
Pesanan pelanggan mana pun bisa dibaca dan diubah siapa saja.
Lebih dari enam endpoint pesanan menerima ID pesanan apa pun bersama ID tamu yang ditebak. Direproduksi langsung: permintaan tanpa autentikasi sama sekali mengembalikan item, harga, dan alamat pengiriman pelanggan lain. Endpoint pembayaran dompet di jalur yang sama tidak punya pemeriksaan saldo. Diperbaiki dengan pembatasan kepemilikan di setiap endpoint yang terpengaruh, sambil menjaga checkout tamu yang sah tetap berfungsi.
Gateway pembayaran yang dimatikan masih bisa menyelesaikan pembayaran.
Mematikan gateway di panel admin hanya menghapusnya dari pilihan pelanggan — URL callback-nya tetap hidup, dan banyak callback gateway menandai pesanan sebagai lunas hanya berdasarkan kata status di URL. Dengan semua gateway dimatikan, sebuah callback tetap berjalan sukses, sehingga pelanggan bisa mengonfirmasi pesanannya sendiri tanpa membayar. Diperbaiki agar gagal-tertutup; 102 pengujian di semua prefiks gateway kini memastikan tidak ada yang berjalan saat nonaktif.
Vendor bisa bertindak atas data vendor lain.
Vendor mana pun bisa mengubah atau menghapus produk, add-on, dan banner toko lain — termasuk banner layar beranda milik admin sendiri. Membalas ulasan memindahkan ulasan itu ke toko vendor yang membalas. Diperbaiki dengan pembatasan per toko.
Backdoor login demo yang aktif — dan apa yang tidak bisa dijangkaunya.
6amMart menyertakan jalan pintas demo supaya peninjau app store bisa masuk tanpa SMS. Kodenya membaca nomor telepon dan kode dari config, dengan nilai demo sebagai cadangan saat config tidak ada — dan config memang tidak ada tepat setelah sebuah situs menjalankan langkah caching produksi standar, yang dilakukan setiap instalasi live. Di situs live, satu nomor yang ditulis langsung di kode diberi kode yang berfungsi tanpa SMS terkirim dan tanpa apa pun di config yang memintanya. Dampaknya terbatas, dan kami menyebutkan batasnya: tidak ada akun pada nomor itu, jadi jalur ini berujung pada akun baru dengan verifikasi telepon dilewati — bukan pengambilalihan akun orang lain yang sudah ada. Nilai cadangan itulah yang membuatnya berbahaya: operator yang belum pernah mendengar pengaturan ini tetap mengirim backdoor tersebut. 28 pemeriksaan otomatis kini membuktikan bahwa ini tidak bisa ada kecuali sengaja diaktifkan.
Seluruh folder proyek bisa dibaca lewat HTTPS.
6amMart mengarahkan web server ke folder aplikasi, bukan ke public/, dan hanya ditahan oleh daftar tolak yang ditulis tangan. Daftar tolak hanya melindungi jalur yang terpikirkan seseorang; empat belas jalur tidak ada di daftar itu, masing-masing dipastikan dengan permintaan nyata — termasuk dump database installer 679 KB, arsip 5.9 MB berisi folder public, dan satu file PHP yang benar-benar dieksekusi server, yang mengembalikan halaman fatal error berisi jalur absolut server. Root web dipindahkan ke public/; keempat belas jalur itu kini mengembalikan 404, dan 19 pemeriksaan otomatis menjaganya tetap begitu.
Cerita pembatasan laju terdiri dari tiga cacat terpisah, bukan satu.
- 1
API sama sekali tidak punya pembatas laju.
Konfigurasi framework mendefinisikan pembatas API 600 per menit, tetapi tidak ada yang pernah menerapkannya — grup middleware API hanya berisi satu entri yang tidak berkaitan dan tidak ada yang lain, jadi pembatas itu hanyalah konfigurasi mati. Diukur sebelum perubahan: 40 percobaan masuk dengan sandi salah pada satu akun, secepat yang bisa dilakukan curl — 40 penolakan, tanpa pembatasan, tanpa jeda, tanpa apa pun tercatat. Kini berlaku tiga batas: cadangan 600/menit, 10/menit untuk percobaan autentikasi yang dikunci pada alamat sekaligus akun yang diserang, dan 5/menit pada rute yang benar-benar mengirim SMS. Terverifikasi: 25 sandi salah beruntun → 10 penolakan lalu 15 pembatasan; akun berbeda dari alamat yang sama dalam jendela waktu yang sama → tidak dibatasi; 60 permintaan penjelajahan biasa dalam satu ledakan → semuanya berhasil.
- 2
Pembatas itu lalu memakai identitas yang tidak dimiliki separuh platform — dan yang satu ini kami temukan sendiri, saat meninjau perbaikan kami sendiri.
Pembatas baru itu memakai pengguna yang sedang masuk, dengan alamat jaringan sebagai cadangan. Tetapi API vendor dan kurir melakukan autentikasi dengan mencari bearer token di sebuah tabel, bukan lewat auth guard, sehingga penggunanya selalu null dan kuncinya jatuh ke alamat. Toko dengan staf di satu koneksi kantor, atau kurir di balik NAT operator, akan berbagi satu jatah 600/menit — dan aplikasi pengiriman melakukan polling setiap 10 detik, jadi shift yang sibuk akan mulai menolak orang yang sedang bekerja. Kuncinya kini jatuh ke hash bearer token terlebih dahulu. Terverifikasi: dua panggilan dengan token vendor → sisa 599 lalu 598 pada penghitungnya sendiri; token pelanggan segera setelahnya → 599 pada jatah terpisah; tanpa token → tetap memakai alamat, 600 utuh.
- 3
Platform tidak bisa melihat pengunjung yang sebenarnya.
Di balik CDN, setiap permintaan datang dari alamat CDN dan aplikasi percaya itulah pengunjungnya — sehingga pembatasan laju membatasi semua pelanggan sebagai satu orang, pemeriksaan penipuan membandingkan alamat yang salah, dan setiap pesanan menyimpan IP proxy alih-alih IP orang yang memesan. Akar penyebabnya: framework menyertakan penanganan proxy di tumpukan globalnya dan 6amMart mengganti tumpukan itu seluruhnya sehingga penanganannya hilang, jadi mengonfigurasi trusted proxy saja tidak punya tempat menempel. Kedua bagian kini sudah ada, dan permintaan yang diteruskan menghasilkan alamat klien yang sebenarnya. Platform kini melihat pengunjung yang sebenarnya alih-alih memperlakukan seluruh internet sebagai satu pengguna.
Sebuah primitif peracunan cache.
Cache daftar menghitung kuncinya dari query string URL, tetapi endpoint-nya membaca parameter lewat metode yang lebih memilih body permintaan setiap kali permintaan menyatakan tipe konten JSON — termasuk pada GET. Jadi satu permintaan bisa meminta satu kata pencarian di URL dan kata lain di body: kuncinya dihitung untuk yang pertama, pencariannya dijalankan untuk yang kedua, dan baris yang salah disimpan di bawah kunci pertama lalu diberikan ke setiap pelanggan asli yang mencarinya sampai entri itu kedaluwarsa. Tanpa autentikasi, dan penyerang memilih kedua bagiannya — produk apa yang dilihat pembeli, dari toko mana, pada harga berapa. Permintaan yang masukannya tidak terlihat oleh kunci kini dijawab sepenuhnya di luar cache.
Juga ditutup
Setiap faktur bisa diunduh siapa saja yang bisa berhitung.
Faktur pesanan, langganan, dan perjalanan bisa ditelusuri berurutan lewat URL.
XSS tersimpan dari vendor ke admin.
Deskripsi produk yang ditulis vendor dirender sebagai HTML mentah di 8 layar admin dan vendor, sehingga vendor bisa menjalankan script di browser admin. Sudah disanitasi, dan dibuktikan aman terhadap 25,726 deskripsi produk live tanpa satu pun teks tampilan yang berubah.
Pengulangan callback pembayaran.
Callback tidak idempoten, jadi callback yang diulang mengkredit pelanggan dua kali. Diperbaiki di tingkat hook untuk seluruh 47 gateway.
Open redirect pada rute pengalihan aplikasi.
Bentuk phishing di domain Anda sendiri. Diperbaiki, lalu diperbaiki lagi saat ditemukan celah backslash dalam peninjauan; uji dengan 17 kasus kini menjaganya.
Dua rute debug publik.
Satu menjalankan perintah penghapusan cache tanpa autentikasi, satunya lagi adalah relai gambar terbuka. Keduanya dihapus.
laravel.log bisa diunduh dari internet.
Berisi nama pengguna database, SQL yang gagal beserta binding-nya, dan jalur server lengkap.
Satu kunci aplikasi dikirim ke setiap instalasi.
File environment contoh membawa kunci asli; file environment baru menyalinnya, dan langkah pembuatan kunci hanya berjalan pada nilai kosong, jadi langkah itu dilewati — setiap instalasi yang dibangun dengan cara itu berjalan pada kunci yang sama, yang tercetak di dalam setiap salinan produk.
Permintaan GET yang mengubah pengaturan — dimitigasi, dan dinyatakan secara sempit.
Pada 6amMart bawaan, mengubah pengaturan hanyalah tautan biasa, sehingga 64 rute GET admin dan vendor menulis state. Crawler, pratinjau tautan, tag gambar, atau permintaan latar belakang bisa mengubah pengaturan saat admin sedang masuk. Ini bukan teori: pada 1 Agustus, profiler performa kami sendiri meminta alamat-alamat itu saat mengukur kecepatan halaman dan mengubah 8 pengaturan live dalam 45 detik — arah teks panel terbalik, halaman landing dimatikan, satu vendor dinonaktifkan. Dipulihkan dan diverifikasi dalam satu jam. Perbaikan yang dikirim adalah satu pengaman yang didaftarkan sekali dan membaca header Fetch Metadata dari browser — yang menyatakan alasan sebuah permintaan dibuat dan tidak bisa dipalsukan oleh JavaScript penyerang — lalu menolak bentuk permintaan yang tidak mungkin berasal dari klik manusia. Terverifikasi langsung: pemuatan alamat pengaturan lewat tag gambar ditolak; prefetch ditolak; permintaan latar belakang lintas situs ditolak; administrator asli yang mengklik tetap berhasil; 338 permintaan latar belakang milik panel itu sendiri tetap berjalan; browser lama yang tidak mengirim header semacam itu tetap berjalan. 102 halaman panel asli dirender identik byte per byte dengan pengaman menyala dan mati, dan 53 pemeriksaan otomatis mencakupnya. Satu pendaftaran mencakup 1,348 rute, termasuk modul yang mendeklarasikan grup rute sendiri.
Jalur eksploitasi dari browser sudah ditutup. Rutenya sendiri masih menulis pada GET — lihat Batas jujur.
Kebenaran — cacat yang menyangkut uang
| Cacat pada 6amMart bawaan | Apa yang diukur |
|---|---|
| Minimum belanja kupon tidak pernah diberlakukan | Admin bisa mengaturnya; kodenya tidak pernah membacanya. Dibuktikan langsung: kupon yang mensyaratkan minimum ₹999 diterima pada pesanan ₹1. Enam kupon live punya minimum yang disetel. Sekarang diberlakukan di ketiga tempat harga pesanan bisa dihitung. |
| Diskon dinilai dengan jam yang salah | Database berjalan pada UTC dan aplikasi pada waktu India — diukur langsung berselisih 5j30m. Diskon malam 18:00–22:00 tidak pernah cocok saat malam dan justru menyala pukul 2–3 pagi. Lebih buruk lagi, layar daftar dan checkout memakai jam yang berbeda, sehingga sebuah toko bisa diiklankan berdiskon tetapi ditagih harga penuh. |
| Jumlah add-on ditagihkan pada add-on yang salah | Jumlah dipasangkan ke add-on berdasarkan posisi dalam daftar, padahal aplikasi pelanggan mengirim urutan menu sementara database mengembalikan urutan ID internal. Diperagakan di server: pesanan yang dimaksud ₹270 ditagih ₹550. Diperbaiki di seluruh 8 tempat dalam kode yang melakukan hal ini. |
| Stok dikurangi pada produk yang salah | Pembelian kampanye mencari produk berdasarkan ID kampanye pada tabel produk. Ketiga ID kampanye live juga ada sebagai ID produk. |
| Pengaman stok di checkout memeriksa angka yang berbeda dari yang ditulisnya | Pemeriksaan akhir membandingkan stok keseluruhan produk; pengurangan terjadi pada stok variasi yang dipilih. Diukur pada data live: 56 produk aktif yang pembelian sahnya akan ditolak, dan 1,451 produk yang penjualan berlebihnya tidak akan terdeteksi. |
| Callback gateway yang berulang mengkredit pembayaran dua kali | Juga terpicu saat pelanggan memuat ulang halaman pengembalian. Diperbaiki di tingkat hook untuk seluruh 47 gateway. |
| Checkout beli-sekarang memakai harga yang dikirim ponsel | Alih-alih keranjang di server. |
| Penarikan dana bisa disetujui dua kali dan membuat dompet minus | Direproduksi langsung: menyetujui dua kali mengkredit total penarikan dua kali dan membuat saldo tertunda menjadi −50.00. Tombol kembali atau klik ganda sudah cukup. |
| ID pesanan diberikan secara manual | Kodenya membaca ID pesanan tertinggi yang ada lalu menambah satu — meniru auto-increment dengan buruk, dan bertabrakan saat checkout bersamaan. |
| Dua kurir bisa menerima pesanan yang sama | Dan dua pelanggan bisa membeli unit terakhir. Balapan periksa-lalu-tulis, kini menjadi klaim database yang atomik, dibuktikan dengan transaksi bersamaan. |
Tentang dua angka yang akan Anda lihat dikutip. Total milik proyek ini sendiri menilai 4 dari lubang keamanan sebagai kritis dan 6 dari cacatnya sebagai menyangkut uang, dari 342 yang diperbaiki. Itu angka yang lebih rendah dan sudah dipublikasikan, jadi itulah yang dipakai halaman ini. Angka itu bukan hitungan item yang tercantum di halaman ini: bagian keamanan di atas menyebut lebih dari empat cacat keamanan dan tabel di atas mencantumkan sepuluh cacat uang, karena kami mencantumkan setiap yang berhasil kami reproduksi, bukan hanya yang masuk dua hitungan tersebut.
Kebenaran non-uang yang layak dicantumkan
- Penjadwal tidak pernah berjalan. Lima tugas latar belakang terjadwal tidak pernah dijalankan sekali pun sejak deployment — entri cron sistem tidak pernah dipasang.
- Tugas pembayaran bulanan berjalan empat kali sebulan (jadwalnya ditulis “hari 28–31” alih-alih “hari terakhir bulan itu”).
- Riwayat pesanan melaporkan setiap toko tanpa rating — 0 bintang di mana-mana, padahal rating asli satu toko adalah 4.31 dari 29 ulasan.
- Pengiriman oleh kurir tidak pernah dihitung untuk popularitas produk — perulangan penambahnya memakai nama properti yang tidak ada pada record tersebut, jadi blok itu diam-diam tidak melakukan apa pun, sehingga setiap peringkat “produk teratas” menjadi melenceng.
- Notifikasi push diam-diam nonaktif — diantrikan ke worker yang mungkin tidak ada; tidak ada yang terkirim, tidak ada error muncul.
- 34 error server di panel admin dan vendor → nol.
- Vendor tanpa baris toko membuat 9 dari 12 halaman panelnya sendiri mati, begitu juga login web vendor dan login aplikasi toko — satu helper bersama mengembalikan elemen pertama dari relasi kosong, yang memunculkan error alih-alih mengembalikan null. 43 pemeriksaan, termasuk pernyataan berpasangan bahwa vendor yang sah tetap lolos.
- Satu laporan admin tidak pernah berfungsi di instalasi mana pun dari perangkat lunak ini — file itu dikompilasi menjadi PHP tidak valid dan selalu gagal. Ditemukan dengan memeriksa seluruh 895 template layar; hanya itu satu-satunya yang rusak.
Apa yang ikut dikirim pada instalasi yang dioptimalkan tetapi tidak ada di versi bawaan
| Kemampuan | Apa itu |
|---|---|
| Rangkaian verifikasi otomatis | Script yang Anda jalankan sendiri. Setiap pernyataan uji dibuktikan gagal pada kode lama sebelum diterima — uji yang lolos di sistem rusak tidak membuktikan apa pun. Pada laporan 9 Agustus, 60 script itu terdiri dari 55 pernyataan uji ditambah 5 alat pelaporan, dan alat pelaporan tidak menyatakan apa pun. Ditambah 49 unit test dan feature test. |
| Bukti reproduksibilitas skema | Database bisa dibangun ulang dari kode saja — dibuktikan dengan membangunnya dari nol dan membandingkan seluruh 184 tabel, kolom demi kolom dan indeks demi indeks, tanpa perbedaan. |
| SixPreflight | Alat kesiapan server: ~134 pemeriksaan pada perangkat keras, PHP, kesehatan aplikasi, izin, web server, caching, pengaturan database, paparan publik, dan setiap layanan luar. Buka di browser sebelum peluncuran dan alat ini memberi tahu apa yang akan rusak. |
| Runbook deployment | Urutan instalasi dan pembaruan yang terdokumentasi beserta jebakannya: perintah mana yang diam-diam menghapus cache config, cache mana yang tidak saling membangun ulang, apa yang dibatalkan panel hosting saat Anda menyimpan sebuah pengaturan. |
| Build iOS | Ketiga aplikasi ditandatangani dan bisa dibangun untuk Apple selain Android — build Apple pertama yang dihasilkan untuk proyek ini. |
| Pelacakan pesanan langsung yang benar-benar menyala | Layanan websocket dinyalakan dan dua cacat yang membuatnya mati diperbaiki; pembaruan sertifikat sudah dibuktikan. |
Periksa sendiri
Periksa sendiri setiap angkanya
Hal paling meyakinkan di halaman ini bukan sebuah angka. Melainkan bahwa Anda bisa memeriksa sendiri setiap angkanya.
Rangkaian verifikasi ikut terpasang bersama instalasi Anda. Di server Anda sendiri:
bash tests/Scripts/run-all.sh # pemeriksaan verifikasiphp tests/Scripts/api-smoke.php # menyapu setiap endpoint API1Setiap pernyataan uji dibuktikan gagal pada kode lama sebelum diterima.
Uji yang lolos di sistem rusak tidak membuktikan apa pun.
2Penyapuan endpoint menembakkan 306 permintaan.
Alat ini melaporkan error server dan waktu respons per endpoint — jadi “nol error server, nol endpoint di atas 250 ms” adalah sesuatu yang Anda jalankan ulang, bukan sesuatu yang harus Anda percaya begitu saja. Baca jumlah yang ditolak pada pengujian Anda sendiri sebelum membaca waktunya; lihat catatan operasional di bawah.
3Rangkaian ini mencakup pernyataan uji keamanan.
Bukan hanya yang soal kecepatan: penyapuan paparan root web, pemeriksaan backdoor OTP demo, pemeriksaan idempotensi hook pembayaran, pengaman lintas akun, pemeriksaan peracunan cache, dan audit rute GET mana yang menulis state.
4Pemeriksaan skema membangun ulang database dari kode saja.
Lalu membandingkan seluruh 184 tabel dengan database live Anda.
Catatan operasional yang jujur Jalankan penyapuan endpoint terlalu sering berturut-turut dan ia akan memicu pembatas laju platform sendiri. Permintaan yang dibatasi tidak melakukan pekerjaan database, jadi total kuerinya turun dan pengujian terlihat lebih cepat padahal hampir tidak menguji apa pun. Pengujian yang sah menunjukkan sekitar 235 permintaan berhasil dan 66–68 ditolak; kalau ratusan ditolak, buang hasil pengujian itu.
Dan keadaan rangkaian uji saat ini, dinyatakan tepat Laporan 9 Agustus mencatat 60 script — 55 pernyataan uji ditambah 5 alat pelaporan — dan 49 unit test dan feature test. Direktorinya sejak itu tumbuh menjadi 86 entri, yang mencakup alat pelaporan dan file lain yang bukan pernyataan uji, jadi itu bukan hitungan pemeriksaan. Pengujian penuh terakhir yang tercatat menjalankan 70 di antaranya: 61 lolos, 2 gagal, 7 dilewati. Kedua kegagalan disebutkan namanya dalam bukti — dua laporan admin sewa yang mengembalikan error server pada instalasi tanpa penyewaan, dan satu peta aset yang hilang — dan setidaknya yang soal sewa sudah diperbaiki sesudahnya. Jalankan ulang rangkaian ini di instalasi Anda sendiri dan baca angka Anda sendiri.
Batas jujur
Apa yang tidak diklaim halaman ini
Halaman yang berkata “inilah yang kami ukur, inilah cara memeriksanya, dan inilah yang belum kami selesaikan” lebih sulit diragukan daripada halaman yang hanya mencetak kemenangannya.
342 cacat ditemukan dan diperbaiki. Tidak ada yang bisa menyebutkan satu per satu apa yang tersisa.
Itulah bentuk jujur dari platform sebesar ini.
Tidak ada bagian dari program ini yang mengukur pekerjaan vendor lain.
Jadi halaman ini tidak mengklaim apa pun tentang build orang lain. Setiap angka di sini adalah script bawaan seperti yang dikirim pada saat itu dibandingkan dengan kode kami yang dioptimalkan, pada satu server.
Setiap angka di halaman ini dibulatkan merugikan kami, tidak pernah menguntungkan kami.
Pada layar yang dilihat pelanggan, peningkatan terukurnya 10× hingga 22×, yang berarti 90 sampai 95% lebih sedikit menunggu — 22× adalah 95.4% dan kami menulis 95. Jika sebuah pengukuran berupa rentang, kelipatannya adalah nilai “sebelum” terendah dibagi nilai “sesudah” tertinggi.
Angka 10 juta pesanan di halaman ini adalah uji skala, bukan performa live.
Angka itu berasal dari database yang dibuat khusus berisi 10,000,000 pesanan, 1,000,000 produk, dan 200,000 pelanggan, sengaja dijalankan dengan buffer pool 128 MB yang kurang memadai supaya terikat I/O seperti server nyata yang kekurangan sumber daya. Instalasi produksi yang diaudit menyimpan 3,282 pesanan.
Enam baris uji skala masih pada atau di atas satu detik, dan kami mencetak sebelas barisnya di bawah.
Badge dispatch 12 s; popular_products 7.1 s; daftar pesanan admin pada offset halaman yang dalam 3.1 s; laporan item 12.5 s untuk satu bulan dan 131 s untuk sepanjang waktu; daftar pelanggan admin sekitar 1–1.5 s. Angka sepanjang waktu pada laporan item adalah hal terburuk yang pernah kami ukur di mana pun, dan pengujian versi bawaan yang seharusnya jadi pembanding dihentikan pada 120 detik, jadi kami bahkan tidak bisa mengklaim ada peningkatan di sana — hanya bahwa milik kami selesai.
Permintaan GET yang mengubah pengaturan dimitigasi, bukan dihilangkan.
Jalur eksploitasi lewat browser sudah ditutup dan diverifikasi; 64 rute admin dan vendor itu sendiri masih menulis state pada GET, dan mengubahnya menjadi form terlindungi sengaja tidak dicoba karena risiko regresinya besar pada platform yang saat ini berjalan di banyak proyek turunan.
Pengamannya lebih luas daripada kerentanannya.
Daftar baca-saja yang tidak berbahaya pun ditolak jika datang sebagai prefetch atau pemuatan gambar, karena memisahkan ~860 alamat baca-saja milik panel dari 64 alamat berbahaya itu membutuhkan tepat daftar rapuh yang kami putuskan untuk tidak tulis. Ada satu saklar satu baris untuk mematikannya.
Pembatasan laju aman karena posisi servernya, bukan karena header tidak bisa dipalsukan.
Konfigurasinya memercayai header yang diteruskan, dan itu hanya berlaku selama tidak ada yang bisa mencapai PHP kecuali lewat rantai proxy. Mesin yang bisa dijangkau langsung memungkinkan klien memalsukan header dan mendapat jatah baru setiap permintaan.
Ukuran unduhan aplikasi hampir tidak berubah.
Sekitar 0.7 MB total, karena kode tak terpakai yang kami hapus sudah dibuang oleh kompiler rilis. Kami tidak membuat klaim apa pun soal ukuran aplikasi.
Tiga hal pada instalasi rujukan masih terbuka dan disebutkan, bukan disembunyikan.
Kunci Google Maps belum dibatasi dan perlu dikunci; kunci privat Apple Sign-In yang ditempatkan oleh helper unggah bawaan 6amMart di penyimpanan publik perlu dicabut dan diterbitkan ulang; dan tiga vendor masih tidak punya baris toko — error 500 yang dulu disebabkan keadaan itu sudah diperbaiki, tetapi keadaannya sendiri masih bisa terjadi karena kedua jalur pendaftaran menyimpan vendor dan toko di luar satu transaksi. Ketiganya ada di dokumen serah terima.
Di server rujukan, kini perangkat kerasnya yang jadi batas, bukan kodenya.
Diuji beban pada 20–40 pengguna bersamaan tanpa error; pada titik itu mesin 2 vCPU sudah jenuh.
Semua benchmark ini berasal dari satu server, satu kumpulan data.
Cukup untuk mengatakan apa yang berubah pada instalasi ini. Bukan pernyataan umum tentang setiap deployment 6amMart.
6amMart bawaan adalah produk komersial yang banyak dipakai.
Cacat di atas dinyatakan sebagai fakta, dan itu sudah cukup.
Uji skala, dicetak lengkap — setiap baris, termasuk yang buruk
Uji skala — database 10 juta pesanan yang dibuat khusus, bukan lalu lintas live.
| Layar | Bawaan | Dioptimalkan | Masih lambat? |
|---|---|---|---|
| Daftar pesanan admin, halaman pertama | 27.4 s | 13.6 ms | |
| Badge jumlah pesanan di setiap halaman vendor | 136 ms | 20 ms | |
| Laporan item, this_week | dihentikan pada 120 s | 542 ms | |
| get_stores | 9.8 s | 901 ms | |
| Badge jumlah pesanan di setiap halaman admin | 8.5 s | 830 ms | |
| Daftar pelanggan admin, halaman pertama | 20.7 s | ~1.0 – 1.5 s | ≥ 1 s |
| Daftar pesanan admin, offset halaman yang dalam | 100 s | 3.1 s | ≥ 1 s |
| popular_products | 12.8 s | 7.1 s | ≥ 1 s |
| Badge dispatch | 29.8 s | 12 s | ≥ 1 s |
| Laporan item, this_month | dihentikan pada 120 s | 12.5 s | ≥ 1 s |
| Laporan item, all_time | dihentikan pada 120 s | 131 s (batas bawah 365 hari) | ≥ 1 s — baris terburuk yang kami punya |
Jika dua sumber berbeda pada satu baris, tabel ini mencetak angka yang kurang menguntungkan di kedua sisi.
Laporan kami sendiri mencatat daftar pelanggan admin pada ~1.0 s sementara log mentah harness mencatat 1.5 s, jadi rentangnya yang dicetak. Laporan mencatat badge admin pada 8.5 s → 830 ms sementara log mentah membaca 57.4 s → 791 ms, dan badge vendor pada 136 ms → 20 ms sementara log mentah membaca 270 ms → 13 ms; pada kedua kasus, nilai “sebelum” yang lebih kecil dan “sesudah” yang lebih besar yang dicetak.
Apakah ini penting bagi saya?
Pada 100,000 pesanan yang realistis — tiga puluh kali volume instalasi yang diaudit saat ini — dan dengan jendela badge pesanan dimatikan, seluruh sembilan layar yang diprofilkan pada volume itu terukur pada atau di bawah 250 ms, dan enam dari sembilan pada atau di bawah 50 ms: badge vendor 3.4 ms, get_latest_products 10 ms, daftar pelanggan 31 ms, laporan item 46 ms, produk populer 47 ms, daftar toko 50 ms, badge dispatch 146 ms, daftar pesanan admin 155 ms, badge sidebar admin 179 ms. Jendela badge (ORDER_BADGE_WINDOW_DAYS=60) adalah pengaturan yang ikut dikirim, dan menyala atau tidaknya mengubah angka-angka ini, jadi kami menyebutkan kondisi saat pengukuran diambil.
FAQ
Pertanyaan yang benar-benar ditanyakan pembeli
Dua belas pertanyaan, dijawab dengan angka yang sama seperti sisa halaman ini.
Apa sebenarnya yang saya beli?
Hal yang sama yang selalu dijual AllsWeb: instalasi, penyiapan, dan konfigurasi lengkap 6amMart di hosting Anda — panel admin, panel vendor, Android APK dan AAB, build iOS, situs web pelanggan, branding Anda, SMTP, Google Maps, Firebase push dan OTP, login sosial, gateway pembayaran Anda, file bahasa Anda, dan source-nya di repositori GitHub privat. Dikirim dalam 1–3 hari kerja setelah kebutuhan Anda lengkap, dengan dukungan seumur hidup gratis untuk masalah penyiapan dan perbaikan kecil. Kode yang dioptimalkan adalah cara instalasi itu dibangun sekarang.
Apakah saya mendapat 6amMart yang sama?
Ya — rilis 6amMart terbaru, apa pun yang sedang dikirim 6amTech saat kami membangun instalasi Anda. Panel admin sama, panel vendor sama, aplikasi pelanggan, toko, dan kurir sama, model data sama, fitur sama. Setiap perubahan performa disyaratkan mengembalikan data identik byte per byte sebelum diterima, jadi layar Anda menampilkan hal yang sama seperti sebelumnya, hanya lebih cepat.
Apakah kode yang dioptimalkan itu berbayar tambahan?
Tidak. Tidak ada produk terpisah, tidak ada lisensi terpisah, dan tidak ada paket premium. Harga instalasi di katalog adalah harganya, dan kode yang dioptimalkan sudah termasuk di dalamnya. Anda tetap membeli dan memiliki lisensi 6amMart Anda sendiri dari CodeCanyon.
Sebenarnya seberapa lebih cepat?
Di server live, dengan CDN dilewati: item unggulan 8.19 s → 0.37 s (22×), kategori teratas 3.34 s → 0.27 s (12×), pencarian produk 1.64–1.96 s → 0.09–0.12 s (minimal 13×), halaman beranda toko ~1.47 s → 0.073–0.096 s (minimal 15×). Kelipatan tiap baris dihitung dengan cara paling tidak menguntungkan yang dimungkinkan pengukurannya. Angka umum di seluruh layar yang dilihat pelanggan adalah 10× hingga 22× lebih cepat — 90 sampai 95% lebih sedikit menunggu.
Angka-angka itu berasal dari mana, dan di perangkat keras apa?
“Sebelum” adalah script bawaan persis seperti yang dikirim CodeCanyon pada saat eksperimen — catatan metode di atas menjelaskan build mana itu dan kenapa catatannya ada. “Sesudah” adalah script yang sama setelah program ini, dengan rilis berikutnya dari vendor ditumpangkan. Keduanya diukur di server 2 vCPU / 3.9 GB yang sama, di sisi server, dengan CDN dilewati — bukan di mesin yang lebih besar, dan bukan dengan CDN yang mengerjakan tugasnya. Dua baris di tabel perbandingan bukan waktu server dan ditandai demikian: hitungan byte keluaran build, dan pengukuran dari ponsel lewat data seluler.
Bisakah saya memverifikasi semua ini sendiri, atau saya harus percaya halaman ini?
Anda bisa memverifikasi semuanya. Rangkaian verifikasi ikut terpasang bersama instalasi Anda: bash tests/Scripts/run-all.sh menjalankan pemeriksaannya dan php tests/Scripts/api-smoke.php menyapu 306 permintaan API lalu mencetak waktu responsnya. Setiap pernyataan uji dibuktikan gagal pada kode lama sebelum diterima, jadi status lolos itu berarti sesuatu. Satu catatan yang lebih baik kami sampaikan daripada Anda temukan sendiri: penyapuan yang sah punya sekitar 66–68 permintaan yang ditolak pembatas laju platform sendiri, dan pengujian dengan ratusan penolakan sebaiknya dibuang.
Apakah pembaruan resmi dari 6amTech masih bisa dipasang di atasnya?
Secara mekanis, ya — sudah pernah dilakukan. Rilis berikutnya dari vendor ditumpangkan ke kode yang dioptimalkan, dan pekerjaan lanjutan masuk setelah laporan 9 Agustus: pengamanan cache, daftar pengeluaran yang dibangun ulang, dan cacat kunci aplikasi yang memengaruhi setiap instalasi yang dibangun dari konfigurasi contoh vendor. Detail jujurnya: perbaikan kami berada di file yang sama dengan yang dikirim 6amTech, jadi rilis vendor adalah penggabungan yang kami kerjakan untuk Anda, bukan penimpaan file demi file yang Anda jalankan sendiri.
Apa yang terjadi saat 6amTech merilis versi 6amMart berikutnya?
Kalau Anda membeli sekarang, Anda mendapatkannya — kami memasang apa pun yang terbaru pada hari kami membangunnya. Untuk instalasi yang kami kirim sebelumnya, berlaku hal yang sama seperti pelanggan mana pun pada script katalog kami mana pun: pindah ke rilis yang lebih baru adalah layanan pembaruan standar seharga 50% dari harga instalasi, karena konfigurasi dari penyiapan pertama Anda dipakai ulang. Menerapkannya ke kode yang dioptimalkan adalah penggabungan yang dijelaskan di jawaban sebelumnya, dan itu pekerjaan kami, bukan pekerjaan Anda.
Masalah keamanan apa yang sebenarnya ada di script bawaan?
Direproduksi, lalu diperbaiki: SQL injection tanpa autentikasi yang bisa dicapai dari setiap daftar toko; pesanan dan alamat pengiriman pelanggan mana pun bisa dibaca tanpa masuk; gateway pembayaran yang dimatikan di admin tetapi callback-nya masih menyelesaikan pembayaran; vendor bisa mengubah produk dan banner vendor lain; backdoor login demo yang aktif (terbatas — jalurnya berujung pada akun baru dengan verifikasi telepon dilewati, bukan pengambilalihan akun yang sudah ada); empat belas jalur proyek bisa dibaca lewat HTTPS, termasuk dump database installer 679 KB; setiap faktur bisa ditelusuri berurutan lewat URL; dan API tanpa pembatas laju sama sekali — 40 percobaan sandi salah berturut-turut semuanya diterima tanpa pembatasan dan tanpa apa pun tercatat.
Apakah tetap cepat saat toko saya membesar?
Sampai kira-kira 100,000 pesanan, ya: sembilan layar diprofilkan pada volume itu, dengan jendela badge pesanan mati, semuanya terukur pada atau di bawah 250 ms dan enam dari sembilan pada atau di bawah 50 ms. Itu tiga puluh kali volume instalasi yang diaudit saat ini. Di atas itu, baca uji skala di bagian Batas jujur di atas — tidak semuanya kemenangan. Pada 10,000,000 pesanan dengan database yang kurang memadai, daftar pesanan admin turun dari 27.4 s menjadi 13.6 ms, tetapi badge dispatch masih 12 s, produk populer 7.1 s, dan laporan item sepanjang waktu 131 s. Itu angka uji skala pada database yang dibuat khusus, bukan server live Anda.
Apakah Anda mengklaim tidak ada cacat yang tersisa?
Tidak. 342 cacat ditemukan dan diperbaiki. Tidak ada yang bisa menyebutkan satu per satu apa yang tersisa di platform sebesar ini. Yang bisa kami tunjukkan adalah apa yang diukur, cara mengukurnya ulang, dan item mana yang masih terbuka — bagian Batas jujur di halaman ini mencantumkannya, termasuk baris uji skala yang masih lambat dan rute yang kami mitigasi alih-alih tulis ulang.
Apa yang masih membuat Anda tidak puas?
Beberapa hal, dan kami lebih suka Anda membacanya di sini. Dalam uji skala 10 juta pesanan, enam baris masih pada atau di atas satu detik — yang terburuk adalah laporan item sepanjang waktu pada 131 detik, dan pengujian versi bawaan yang seharusnya jadi pembanding dihentikan pada 120 detik, jadi kami sama sekali tidak bisa mengklaim peningkatan di sana; badge dispatch 12 detik. Enam puluh empat rute admin dan vendor masih mengubah state pada GET biasa — jalur eksploitasi lewat browser sudah ditutup dan diverifikasi, tetapi rutenya sendiri belum diubah. Dan pada instalasi rujukan, kunci Google Maps belum dibatasi, satu kunci Apple Sign-In perlu dicabut dan diterbitkan ulang, dan tiga vendor masih tidak punya baris toko.
Alat pendamping
Di mana posisi SixPanel dan SixPreflight
Semua di atas adalah tentang kode 6amMart itu sendiri. Dua alat AllsWeb berada di kedua sisinya — yang satu menjalankan server tempat toko itu hidup, yang lain memberi tahu apakah server yang sudah Anda punya siap untuknya. Angka keduanya diukur pada waktu berbeda di mesin berbeda, jadi kami menyimpannya di tabel sendiri dan tidak pernah mencampurnya dengan angka di atas.
SixPanel
Kalau Anda ingin servernya dikelola
Apa itu
Panel manajemen yang menjalankan satu toko 6amMart, atau beberapa, di satu VPS sewaan — MariaDB, Redis, nginx, layanan websocket untuk pelacakan pesanan langsung, dan storefront Next.js opsional. Dua runtime: yang direkomendasikan memasang semuanya langsung di mesin dari arsip distribusi rilis itu sendiri di bawah systemd, dan SixPanel Docker menjalankan stack yang sama sebagai layanan Docker Compose. Satu perintah pemasangan, deploy dari zip CodeCanyon atau dari git, sertifikat Let's Encrypt otomatis dengan pembaruan otomatis, backup inkremental restic terjadwal dengan retensi, virtual host per proyek, autotuning perangkat keras, dan watchdog yang menyembuhkan diri sendiri dan me-restart layanan yang berjalan tetapi rusak. Tiga permukaan: panel di browser, perintah sixpanel di host, dan installer. Disertai manual pelanggan 24 bab, disajikan di dalam panel.
Diukur, dan aman dipublikasikan
| Apa yang diukur | Angkanya, beserta kondisinya |
|---|---|
| Permintaan yang dilayani — endpoint pencarian, 20 bersamaan, 30 detik | Server 2 core / 4 GB menyelesaikan sekitar 53 permintaan per detik pada katalog toko nyata berisi 66,701 pesanan, dengan database menjawab 99.99% pembacaan dari memori. Ini menggambarkan endpoint itu, kumpulan data itu, dan dua core. Ini bukan angka umum untuk platformnya. |
| Waktu instalasi tanpa pengawasan | 273 – 303 detik pada tiga sistem operasi yang diuji — sekitar lima menit |
| Kecepatan melawan pesaing yang sudah disetel | 1,76× lebih cepat daripada aaPanel yang disetel penuh pada satu permintaan dan 1,82× dengan empat sekaligus, pada perangkat keras identik yang menjalankan toko yang sama berisi 66.701 pesanan — dengan sekitar 60 % selisihnya berasal dari pembatasan direktori PHP, 8 % dari mode JIT yang keliru, 0 % dari versi PHP, dan sekitar 32 % diterbitkan sebagai belum terjelaskan |
| OS yang direkomendasikan | Ubuntu 26.04 LTS, pembaruan keamanan sampai April 2031. Ubuntu 24.04 LTS dan Debian 13 adalah dua rilis lain yang didukung — tiga total, dan tidak ada yang lain |
Satu hal lagi yang layak disebut, karena hampir tidak ada yang mempublikasikannya. Kami membandingkan tiga sistem operasi pada perangkat keras identik dengan data nyata yang sama. Hasilnya seri — selisih antar sistem lebih kecil daripada selisih satu mesin dengan dirinya sendiri. Jadi kami memilih berdasarkan sisa masa dukungan, bukan kecepatan, dan kami tidak akan mengutip selisih kecepatan yang tidak bisa kami ukur.
Batas jujur — SixPanel
- Cadangan dipulihkan ke mesin yang sama. Memulihkan ke mesin lain meninggalkan sandi database dan jalur mesin lama sehingga aplikasi tidak bisa terhubung sampai Update dijalankan; dan tugas pemulihan tidak pernah menjalankan langkah migrasi database, jadi dump lama di bawah kode baru tertinggal dari skema. Keduanya tercatat rusak — tercatat, bukan diperbaiki — dan keduanya punya solusi manual.
- Watchdog swasembuh tidak bisa melihat dua layanan dalam daftar fitur di atas. Layanan websocket dan storefront Next.js opsional tidak membawa healthcheck, jadi watchdog tidak mencakup keduanya. Item terbuka.
- Rollback tidak membatalkan migrasi database. Rollback kode setelah migrasi memerlukan pemulihan cadangan.
- Panel membaca sertifikat TLS-nya sendiri sekali saat boot. Tugas pembaruan harian memuat ulang nginx tetapi tidak memuat ulang panel, jadi panel perlu di-restart untuk memakai sertifikat yang sudah diperbarui.
- Panel setara root di mesin itu secara bawaan — ia memasang paket, menulis konfigurasi sistem, dan memulai ulang layanan. Pada lingkungan Docker ia juga memasang soket Docker dan mengaitkan direktori tumpukan dengan izin tulis.
- Hanya ada tepat satu akun admin dan tidak ada peran. Tidak ada multi-pengguna, tidak ada tim.
- Hanya mesin 4 GB yang diukur. Tidak ada di halaman ini yang menggambarkan 8 GB atau lebih besar.
Kapan SixPanel cocok
Anda menyewa VPS dan lebih suka tidak mengurus sendiri nginx, penyetelan MariaDB, sertifikat, cadangan, dan deploy — atau Anda ingin lebih dari satu toko di satu server.
SixPreflight
Kalau Anda ingin tahu apa yang akan rusak sebelum peluncuran
Apa itu
Alat PHP kecil yang Anda letakkan di folder public/ situs Laravel Anda lalu dibuka di browser di balik sandi. Alat ini menjalankan kira-kira 134 pemeriksaan pada perangkat keras, PHP, kesehatan aplikasi, file environment, izin, web server, caching, pengaturan database, paparan publik, dan setiap layanan luar — pembayaran, email, SMS, peta, push — dengan benar-benar menghubungi masing-masing, bukan sekadar membaca pengaturan. Hasilnya berupa nilai huruf, kesimpulan bahasa sederhana, dan daftar perbaikan yang diurutkan berdasarkan akibatnya, lengkap dengan nilai siap tempel jika ada. Anda mendapat rilis terkini.
Pada instalasi rujukan
Hasilnya 103 lolos, 7 gagal, 24 peringatan — dan kegagalannya adalah pengaturan hosting, bukan kesalahan aplikasi.
Kapan SixPreflight cocok
Pakai aaPanel, CloudPanel, atau cPanel? SixPreflight untuk Anda. Menjalankan SixPanel? Pemeriksaan ini sudah tertanam di halaman Shop check-up-nya.
Sekarang semuanya merekomendasikan sistem operasi yang sama, dan alasannya bukan kecepatan. SixPanel, SixPanel Docker, dan SixPreflight semuanya merekomendasikan Ubuntu 26.04 LTS. Runtime native mengambil PHP, MariaDB, nginx, dan Redis dari arsip distribusi rilis itu sendiri, dan ketiga rilis yang didukung membawa set yang bekerja — 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. Tidak ada di sini yang merupakan rekomendasi kecepatan: di enam sumbu yang diukur, tidak ada pertukaran versi yang menghasilkan perbedaan yang layak dilaporkan, dan dua mesin identik byte demi byte berselisih 11,6 % satu sama lain. Yang menentukan adalah sisa masa dukungan — 26.04 dipatch sampai April 2031.
Yang mana yang saya butuhkan?
| Situasi Anda | Jawabannya |
|---|---|
| Anda ingin 6amMart dipasang, atau 6amMart Anda yang sekarang lambat atau pernah membuat masalah pada harga atau pembayaran | Instalasi 6amMart yang dioptimalkan |
| Anda punya VPS dan tidak ingin mengurus sendiri nginx, MariaDB, SSL, cadangan, dan deploy | SixPanel |
| Anda sudah punya server di panel lain dan ingin tahu apa yang akan rusak sebelum peluncuran | SixPreflight |
Setiap angka di halaman ini diukur pada instalasi live
Dan rangkaian uji yang mengukurnya ikut terpasang bersama build Anda.
Butuh sesuatu yang dibangun dari nol? Bicarakan pekerjaan kustom dengan kami