SixPanel: একটি কাজের জন্য তৈরি হোস্টিং প্যানেল — 6amMart চালানো
আপনি একটি নতুন সার্ভার ভাড়া নেন, একটি কমান্ড চালান, আর ফিরে পান এমন একটি ওয়েব পেজ যা আপনার দোকান চালায়। SixPanel বসিয়ে দেয় ওয়েব সার্ভার, ডেটাবেস, PHP, ক্যাশ, ব্যাকগ্রাউন্ড ওয়ার্কার, শিডিউলার, websocket সার্ভার ও HTTPS — সবই এমনভাবে কনফিগার করা, 6amMart-এর আসলে যেমন দরকার।
সবকিছু আপনার সার্ভারে চলে। আপনার ডেটাবেস, আপনার ছবি, আপনার গ্রাহকদের ডেটা।
- একই হার্ডওয়্যারে, একই দোকানে, মেপে দেখা — পূর্ণভাবে টিউন করা aaPanel-এর চেয়ে দ্রুত
1.76×
একই হার্ডওয়্যারে, একই দোকানে, মেপে দেখা — পূর্ণভাবে টিউন করা aaPanel-এর চেয়ে দ্রুত
- একটি পুরো দোকান চালায়
2 cores / 4 GB
একটি পুরো দোকান চালায়
- CodeCanyon-এ প্রকাশিত, প্রথম সেটআপ আমরাই করে দিই
ফ্রি
CodeCanyon-এ প্রকাশিত, প্রথম সেটআপ আমরাই করে দিই
- প্যানেল ইন্টারফেসের ভাষা
8
প্যানেল ইন্টারফেসের ভাষা
একটি AI সহকারীর সাথে এই পৃষ্ঠাটি পড়ছেন?
SixPanel নেওয়া
SixPanel একটিমাত্র কমান্ডেই ইনস্টল হয়। সাইন আপ করার কিছু নেই, কোনো কী বসাতে হয় না, কোনো কোড পেস্ট করতে হয় না — সবার জন্য একই কমান্ড। এটি বিনামূল্যে।
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bashroot হিসেবে চলা কমান্ডকে ঠিকানা রক্ষা করে না — রক্ষা করে রিলিজের সই। ইনস্টলার আমাদের সাইনিং কী বহন করে এবং যে ফাইল মেলে না তা আপনাআপনি বাতিল করে দেয়। ইনস্টল পাতায় এটি ব্যাখ্যা করা আছে.
ডাউনলোডের আগে চালিয়ে দেখুন
কেবল-পড়ার লগইন
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.
SixPanel নিন
Free- আপডেট অন্তর্ভুক্ত — প্রতিটি রিলিজ কোনো বাড়তি খরচ ছাড়াই CodeCanyon-এ যায়, আর প্যানেল নিজেও নিজেকে জায়গাতেই আপডেট করতে পারে। কোনো লাইসেন্স সার্ভার নেই, নবায়ন করার মতো কোনো কী নেই।
- প্রথম সেটআপ বিনামূল্যে — আপনার পারচেজ কোড আর সার্ভারের তথ্য পাঠান WhatsApp-এ বা ইমেলে.
সক্রিয় করার কিছু নেই — এটি আপনার নিজের সার্ভারে চলে, বাইরে কিছু জানায় না, আর এই সাইট বন্ধ থাকলেও কাজ করতে থাকে।
এটি কী, আর কীসের জায়গা নেয়
স্ক্রিপ্টের মালিক আপনি। সার্ভারটি তবু কাউকে চালাতে হয়।
আপনি CodeCanyon থেকে 6amMart স্ক্রিপ্ট কিনেছেন। সেটি ফাইলের একটি ফোল্ডার। একটি অর্ডার নেওয়ার আগে কাউকে একটি ওয়েব সার্ভার, একটি ডেটাবেস, PHP, একটি ক্যাশ, একটি ব্যাকগ্রাউন্ড ওয়ার্কার ও একটি HTTPS সার্টিফিকেট বসাতে হয় — আর তারপর সেই সবকিছু চালু রাখতে হয়।
SixPanel সেই কাজটাই করে। আপনি একটি নতুন সার্ভার ভাড়া নেন, একটি কমান্ড চালান, আর ফেরত পান একটি ওয়েব কন্ট্রোল প্যানেল। সেই প্যানেল থেকেই আপনি ডোমেইন যুক্ত করেন, ফ্রি HTTPS নেন, git থেকে আপনার 6amMart কোড ইনস্টল করেন, আপডেট করেন, ব্যাকআপ নেন, আর কিছু ভাঙলে কী ভেঙেছে তা দেখেন।
সবকিছু আপনার সার্ভারে চলে। আপনার ডেটাবেস, আপনার ছবি, আপনার গ্রাহকদের ডেটা।
চালানোর তিনটি উপায়
প্যানেল
ব্রাউজারে। প্রায় সব কাজই আপনি এখানেই করেন।
sixpanel কমান্ড
সার্ভারে, যখন প্যানেল খুলছে না।
ইনস্টলার
যেটি আপনি একবারই চালান।
এটি থাকলে বনাম না থাকলে
প্রতিটি সারি একই কাজ, দুইভাবে করা। বাঁ দিকে SixPanel ছাড়া 6amMart চালাতে আপনার কাছে যা চাওয়া হয়; ডান দিকে এটির সাথে সেটি যা হয়ে দাঁড়ায়।
সার্ভার চালু করা
এটি ছাড়া
হাতে সার্ভার বানানো — nginx, PHP-FPM, MariaDB, Redis, certbot, cron, একটি প্রসেস সুপারভাইজার — আর সেই সবকিছু চালু রাখা
SixPanel দিয়ে
একটি ইনস্টল কমান্ড। systemd-ই সুপারভাইজর — ক্র্যাশে restart, reboot-এ restart, মেমরি সীমা, log rotation এবং প্রতিটি service-এ একটি health check, এক জায়গায় ঘোষিত। Docker runtime-এ, Docker Compose একই কাজ করে।
ডেটাবেস আর PHP-র মাপ ঠিক করা
এটি ছাড়া
ডেটাবেস ও PHP সেটিংস আন্দাজ করা, কিংবা টিউন করানোর জন্য টাকা দেওয়া
SixPanel দিয়ে
Autotune আসল মেশিন পড়ে আর মাপগুলো লিখে দেয়: PHP ওয়ার্কার, ডেটাবেসের বাফার পুল, ক্যাশের মেমরি, টেম্পোরারি টেবিল, sort ও join বাফার আর রিডু লগ। এটি 1 কোর / 2 GB থেকে 16 কোর / 32 GB পর্যন্ত কভার করে, আর যে দুই জায়গায় ওই সংখ্যাগুলো হিসাব হয় প্রতিটি বিল্ডে দুটিকে মিলিয়ে দেখা হয় — কারণ একবার 432টি মানের মধ্যে 66টিতে দুটির অমিল ছিল।
দোকানে একটি পরিবর্তন পাঠানো
এটি ছাড়া
প্রতিবার ডিপ্লয়ের জন্য একজন ডেভেলপারকে টাকা দেওয়া
SixPanel দিয়ে
git-এ push করুন, দোকান আপডেট হয়ে যায়। ডিপ্লয়ের ইতিহাস ও রোলব্যাক, শেষ 30টি ডিপ্লয় রেখে দেওয়া হয়।
ব্যাকআপ কাজ করে জানা
এটি ছাড়া
ব্যাকআপ কাজ করবে বলে আশা করা
SixPanel দিয়ে
ব্যাকআপ রিটেনশনসহ নির্ধারিত সময়ে চলে, আর সপ্তাহে একবার প্যানেল সবচেয়ে নতুন ব্যাকআপটি একটি ফেলে দেওয়া ডেটাবেসে লোড করে, ভেতরে কী আছে গুনে দেখে, তারপর সেটি মুছে ফেলে।
দোকান বসে গেলে
এটি ছাড়া
দোকান কেন বন্ধ তা জানতে স্ট্যাক ট্রেস পড়া
SixPanel দিয়ে
প্রায় বিশটি পরীক্ষার একটি হেলথ পেজ, প্রতিটির সাথে পরিণাম নিয়ে একটি সহজ বাক্য আর ঠিক একটি ফিক্স বোতাম।
এতে কী খরচ
এটি ছাড়া
ওই স্ট্যাকটি নিজে বানানো আর রক্ষণাবেক্ষণ করাই খরচ — সেটি আপনি ঘণ্টায় দিন বা বিলে।
SixPanel দিয়ে
কিছুই না। SixPanel CodeCanyon-এ ফ্রি, প্রথম ইনস্টলেশন ও সেটআপ ফ্রি, আর ইনস্টল কমান্ডটি সবার জন্য একই পাবলিক কমান্ড — কোনো কী বসাতে হয় না, কোনো কোড পেস্ট করতে হয় না। আপডেট আসে CodeCanyon-এর মাধ্যমে, আর প্যানেল নিজেও নিজেকে আপডেট করতে পারে।
এটি কীসের জায়গা নেয় না
এটি আপনাকে 6amMart স্ক্রিপ্ট বিক্রি করে না।
সেটি আপনি CodeCanyon থেকে কেনেন, আর SixPanel আপনার আগে থেকেই কেনা কোডটি ইনস্টল করে।
এটি শেয়ার্ড হোস্টিং নয়।
কোনো cPanel অ্যাকাউন্ট নেই, মেশিনে অন্য কোনো ওয়েবসাইট নেই। SixPanel পুরো সার্ভারটাই চায়।
এটি আপনার দোকান চালায় না।
দাম, প্রোডাক্ট, ড্রাইভার ও অর্ডার থাকে 6amMart-এর নিজের অ্যাডমিন প্যানেলে।
এটি CDN বা DDoS সার্ভিস নয়।
আসল এজ স্তর হলো Cloudflare, আর ডকুমেন্টেশনে সেটাই লেখা আছে।
চালানোর দুটি উপায়
একটি প্যানেল, দুটি রানটাইম — এবং এর একটিই সুপারিশ করা হয়
দুটোই একই পণ্য, একই প্যানেল, একই কমান্ড এবং একই ম্যানুয়াল নিয়ে। পার্থক্য কেবল নিচের সফটওয়্যার কীভাবে ইনস্টল হয় তাতে, আর সেই পার্থক্য মেপে দেখা যায়।
- সুপারিশকৃত
SixPanel
সরাসরি সার্ভারেই চলে
nginx, PHP-FPM, MariaDB আর Redis উবুন্টুর নিজস্ব প্যাকেজ থেকে ইনস্টল হয় এবং systemd সেগুলো দেখাশোনা করে। কিছুই কনটেইনারে নয়, তাই প্রতিটি ধাপ একটি ইউনিক্স সকেটের মধ্য দিয়ে যায় এবং ডেটাবেস কনটেইনারের বদলে আসল মেশিনের জন্য টিউন করা। দুটোর মধ্যে এটিই দ্রুততর, এবং নতুন সব কাজ এখানেই হচ্ছে।
ইনস্টল কমান্ড
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bash- অপারেটিং সিস্টেম
- Ubuntu 26.04 LTS (সুপারিশকৃত), Ubuntu 24.04 LTS, বা Debian 13
- PHP
- Ubuntu 26.04-এ 8.5, Debian 13-এ 8.4, Ubuntu 24.04-এ 8.3 — সবসময় রিলিজের নিজের প্যাকেজ
- ডেটাবেস
- Ubuntu 26.04 ও Debian 13-এ MariaDB 11.8, Ubuntu 24.04-এ 10.11 — একই আর্কাইভ থেকে
- দেখাশোনা করে
- systemd
SixPanel Docker
কনটেইনারে চলে
একই স্ট্যাক, Docker Compose সার্ভিস হিসেবে। এর সুবিধা হলো PHP ও ডেটাবেসের সংস্করণ হোস্টের উপর একেবারেই নির্ভর করে না: যে রিলিজেই চালান, ইমেজগুলো আটকানো থাকে PHP 8.4 আর MariaDB 10.11-এ। এটি এখনো ইনস্টল হয়, এবং যেসব সার্ভারে ইতিমধ্যেই চলছে সেগুলো আপডেট পেতে থাকে।
ইনস্টল কমান্ড
curl -fsSL https://installer.allsweb.net/sixpanel-docker/install.sh | sudo bash- অপারেটিং সিস্টেম
- Ubuntu 24.04 / 26.04 LTS, Debian 12 / 13
- PHP
- 8.4, কনটেইনারের ভিতরে
- ডেটাবেস
- MariaDB 10.11, কনটেইনারের ভিতরে
- দেখাশোনা করে
- Docker Compose
কোনটি বেছে নেবেন?
নির্দিষ্ট কোনো কারণ অন্যটিকে বাধ্যতামূলক না করলে SixPanel বেছে নিন। মাপা প্রতিটি এন্ডপয়েন্টে এটি দ্রুততর, প্রজেক্টগুলোকে PHP-এর ভিতরে নয় বরং কার্নেল স্তরে আলাদা রাখে, আর এটিই সেই রানটাইম যা উন্নত হতে থাকছে।
SixPanel Docker নিন যদি চান পুরো স্ট্যাক কনটেইনারে আলাদা থাকুক, কিংবা যদি বিশেষভাবেই এমন একটি রিলিজে MariaDB 10.11 দরকার হয় যার আর্কাইভে সেটি নেই — হোস্টে যা-ই থাকুক, ইমেজগুলো PHP 8.4 আর MariaDB 10.11-এ আটকানো। এটি Debian 12-তেও এখনো বসে, তবে সেখানে নতুন দোকান শুরু করবেন না: Debian 12-এর নিরাপত্তা সাপোর্ট জুলাই 2026-এ শেষ হয়েছে, আর কার্নেল, glibc, Docker ও OpenSSH এখনো হোস্টের আর্কাইভ থেকেই আসে।
সরাসরি বলি: নতুন উন্নয়ন যাচ্ছে নেটিভ রানটাইমে। SixPanel Docker রক্ষণাবেক্ষণ করা হয়, বাড়ানো হয় না। আজ ইনস্টল করছেন এবং অপারেটিং সিস্টেম বেছে নেওয়ার স্বাধীনতা থাকলে নেটিভটাই নিন।
পরিমাপ করা, দাবি নয়
তিনটি সার্ভার, একই দোকান, এক পার্থক্য
প্রতিটি পারফরম্যান্স সংখ্যা এই পৃষ্ঠায় একটি রাউন্ড পরিমাপ থেকে আসে প্রকৃত সার্ভারে একটি প্রকৃত দোকানের ডেটা চালিয়ে। Setup, পদ্ধতি এবং script published, এবং তাই অংশ যা এখনও unexplained।
1.76×
একটি সম্পূর্ণ সুর aaPanel-এর চেয়ে দ্রুত
চারটি অনুরোধ একসাথে এলে 1.82×। উভয় সার্ভারে PHP পর্যন্ত পৌঁছানো এন্ডপয়েন্টগুলোতে মাপা।
এটি কিভাবে পরিমাপ করা হয়েছিল
- তিনটি সার্ভার
- AMD EPYC 7713, 2 vCPU, 4 GB, Ubuntu 24.04 — যে প্যানেলটি পরীক্ষা হচ্ছে সেটি ছাড়া সবই অভিন্ন
- একই application
- তিনটিতেই একই 6amMart কোড, বাইট ধরে ধরে যাচাই করা: অভিন্ন ডিপেনডেন্সি লকফাইল, আর অ্যাপ্লিকেশন, রুট, মডিউল ও কনফিগারেশন জুড়ে অভিন্ন হ্যাশ
- একই দোকান
- 66,701 অর্ডার · 3,865 আইটেম · 85 স্টোর · 17,534 গ্রাহক — একটি আসল ডেটাসেট, সারি ধরে ধরে কপি করা
- পদ্ধতি
- প্রতিটি মেশিন নিজের আসল হোস্টনেম ও সার্টিফিকেট দিয়ে loopback-এ নিজেকেই মাপে। একটি বাতিল করা ওয়ার্ম-আপের পর প্রতি ঘরে 40টি স্যাম্পল, আর রিপোর্ট করা প্রতিটি সংখ্যাই পর্যায়ক্রমিক জোড়া পাসের মিডিয়ান।
- চুপচাপ কিছুই ফেলে দেওয়া হয়নি
- প্রকাশিত প্রতিটি সারিতে শূন্য রেট-লিমিটেড রেসপন্স আর শূন্য এরর। আটকে দেওয়া বা ব্যর্থ অনুরোধ খুব দ্রুত উত্তর দেয়, তাই যে রান সেগুলো লুকিয়ে রাখে সেটি সত্যের চেয়ে ভালো সংখ্যা দেখায়।
প্রতিটি endpoint, সব চার configuration
Median millisecond — একটি request / চার একবার। Lower better।
| Endpoint | SixPanel | SixPanel Docker | aaPanel, stock | aaPanel, সুর করা |
|---|---|---|---|---|
/api/v1/categoriesPHP-তে forced সব তিনটিতে — cleanest like-for-like সারি | 29.146.9 | 34.570.9 | 52.0103.6 | 56.199.9 |
/api/v1/stores/get-stores/allStore listing প্রতিটি গ্রাহক প্রথমে দেখে | 17.933.3 | 24.545.0 | 37.876.4 | 38.084.2 |
/api/v1/items/searchHeaviest read application-এ | 18.035.9 | 25.143.2 | 44.368.3 | 40.971.1 |
/api/v1/items/popularJoin সম্পূর্ণ catalogue জুড়ে | 41.677.2 | 50.794.6 | 58.4112.1 | 65.3122.9 |
/api/v1/customer/order/listSigned in এবং uncacheable — slowest call প্রতিটি box-এ | 102.1191.8 | 123.3242.3 | 139.6245.8 | 152.7288.9 |
/ (admin entry)SixPanel 430 বাইটে রিডাইরেক্ট করে; aaPanel 352 KB রেন্ডার করেভিন্ন কাজ | 59.6102.7 | 63.5156.3 | 76.7144.5 | 84.8171.2 |
storefront homeSixPanel render পৃষ্ঠা; aaPanel proxy-cache hitভিন্ন কাজ | 54.3104.0 | 111.4213.5 | 83.0— | —— |
websocket handshakeসময় connection গৃহীত করা | 2.35.8 | 4.211.6 | 2.66.3 | —— |
Green সেই সারিতে fastest configuration
দুটি সারি marked কারণ server একই কাজ করছে না তাদের মধ্যে।
তারপর প্রতিদ্বন্দ্বী fully সুর, gap close না।
Beat competitor এটি ডিফল্ট setting-এ prove না। তাই aaPanel box সুর করা।
- PHP opcache 128 MB থেকে 256 MB-এ তোলা, টাইমস্ট্যাম্প যাচাই বন্ধ করে
- ডেটাবেসের বাফার পুল 256 MB থেকে 1152 MB-এ তোলা — সাড়ে চার গুণ বড়
- ডেটাবেসের লগ ফাইল 128 MB থেকে 320 MB-এ তোলা, আর কোয়েরি ক্যাশ বন্ধ
- PHP ওয়ার্কার অতিরিক্ত-প্রতিশ্রুত 50 থেকে মাপমতো 14-তে সংশোধিত
- পাথ ক্যাশ চার গুণ আর ওয়েব সার্ভারের বাফার দ্বিগুণ
এর PHP 8.4 আর এর JIT কম্পাইলার ইচ্ছাকৃতভাবেই চালু রাখা হয়েছিল। ওগুলো এর সুবিধা, আর সেগুলো কেড়ে নিলে পরীক্ষাটাই পক্ষপাতদুষ্ট হয়ে যেত।
স্টক মেশিনের বিপরীতে SixPanel ছিল 1.65× / 1.80× দ্রুত। পূর্ণভাবে টিউন করা মেশিনের বিপরীতে এটি 1.76× / 1.82×। ফারাকটা বরং সামান্য উল্টো দিকেই সরেছে।
ডেটাবেস ব্যাটারি একটুও নড়েনি। সাড়ে চার গুণ বড় বাফার পুলে কিছুই বদলায়নি, কারণ এই রিপোর্টগুলো আগে থেকেই মেমরিতে থাকা রো নিয়ে প্রসেসর-নির্ভর কাজ। ভেতরের হিসাব উন্নত হয়েছে ঠিকই — ক্যাশ হিট রেট 99.856% থেকে 99.930%, ডিস্কে গড়িয়ে পড়া টেম্পোরারি টেবিল 47.3% থেকে 22.1%-এ — কিন্তু রেসপন্স টাইম সেটি অনুসরণ করেনি।
Gap আসলে কোথা থেকে আসে
Speed claim খুব মূল্যবান কারণ ছাড়াই। তাই পার্থক্য taken ছিল একবার এক variable।
| Configuration | একটি অনুরোধ | এক সময়ে চার |
|---|---|---|
| যেভাবে দুটি box জাহির | 1.99× | 1.91× |
| aaPanel-র directory restriction বন্ধ করার পরে | 1.32× | 1.29× |
| এটি JIT compiler মোড সংশোধন করার পরে | ≈1.25× | ≈1.21× |
Gap, attributed
- একটি PHP directory restriction60%
- ভুল JIT compiler মোড8%
- PHP version0%
- এখনও unexplained32%
পার্থক্যের এক-তৃতীয়াংশ account করা হয় না, এবং unexplained হিসাবে প্রকাশ করা হয়
Shape matter বেশি ratio চেয়ে
এই খরচটা প্রতি অনুরোধে একটি নির্দিষ্ট খরচ, তাই ছোট কাজে এটিই প্রধান হয়ে ওঠে আর বড় কাজে মিলিয়ে যায়। একই 20.9 সেকেন্ডের অ্যাডমিন রিপোর্টে দুই মেশিনের ফারাক মাত্র 1.17×। আপনার দোকান যদি মূলত ভারী রিপোর্টের হয়, পার্থক্য অল্পই হবে। আর যদি মূলত ফোন-অ্যাপের API কল হয় — খাবার-ডেলিভারির দোকান তো মূলত তা-ই — তবে পার্থক্যটাই পুরোটা।
কাজ, সম্পূর্ণভাবে
সবচেয়ে বড় একক কারণ ছিল একটিমাত্র PHP সেটিং, আর সেটি প্রতিটি অনুরোধে 16 থেকে 26 ms খরচ করত≈60% ফারাক
aaPanel সীমিত করে দেয় PHP কোন কোন ডিরেক্টরি ছুঁতে পারবে। সেটি সত্যিকারের একটি নিরাপত্তা বৈশিষ্ট্য, তাই বাড়তি বোঝা বলে উড়িয়ে দেওয়ার বদলে এটি সত্যিকারের একটি মাপ পাওয়ার যোগ্য ছিল।
তিনটি পর্যায়ক্রমিক জোড়া, যার “বন্ধ” বাহুটি একটি খালি সেটিংস ফাইল লেখে — যাতে প্রতি-ডিরেক্টরি স্ক্যানটি দুই বাহুতেই ঘটে; নইলে তুলনাটি সেটিং নয়, স্ক্যানের সময়ই মাপত।
প্রতিটি এন্ডপয়েন্ট 17% থেকে 46%-এর মধ্যে সরেছে। একটি স্ট্যাটিক ফাইল, যা PHP পর্যন্ত আদৌ পৌঁছায় না, একটুও সরেনি — সেটিই কন্ট্রোল, আর সেটিই বাকিটাকে কাকতালীয় নয়, ফলাফল করে তোলে। এই মেশিনগুলোতে বাহু-থেকে-বাহু বিস্তার 1% থেকে 13%।
এরপর কার্যপ্রণালীটি তিনটি আলাদা উপায়ে গুনে দেখা হয়েছে: সীমাবদ্ধতা চালু থাকলে প্রতি অনুরোধে 5,862টি ফাইলসিস্টেম লুকআপ, বন্ধ থাকলে 214টি, আর SixPanel-এ 217টি। চালু থাকলে 400টি পাথ রেজলিউশন PHP-র পাথ ক্যাশে একটিও এন্ট্রি যোগ করে না; বন্ধ থাকলে যোগ করে 509টি। ক্যাশটি আদতে নিষ্ক্রিয়ই থাকে, আর এ কারণেই aaPanel-এর নিজের টিউন করা ক্যাশ-আকারের সেটিং তার কোনো কাজে আসেনি।
উল্টো দিক থেকে দ্বিতীয় একটি মেশিনে নিশ্চিত করা: SixPanel-এ একই সীমাবদ্ধতা চালু করলে প্রতি অনুরোধে বাড়তি 17 থেকে 23 ms ফিরে এসেছে।
সার্ভার চালালে জানা দরকার: এই সেটিংটি ছিল একটি প্রতি-ডিরেক্টরি ফাইলে, যা অন্য চারটি জায়গা দেখায়ইনি। যে প্রসেসটি আসলে অনুরোধ পরিবেশন করে, তার থেকে মানটি পড়ে দেখাই একমাত্র নির্ভরযোগ্য যাচাই।
| Endpoint | Restriction চালু | Restriction বন্ধ | পরিবর্তন |
|---|---|---|---|
/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 assetControl — কখনও PHP পৌঁছায় না | 0.4 | 0.4 | 0% |
aaPanel এই application-র জন্য ভুল JIT compiler মোড চালায়≈8% ফারাক
PHP-র JIT সেটিং একটি চার-অঙ্কের সংখ্যা, চালু/বন্ধের সুইচ নয়, আর নাম-ধরা দুটি মোড আলাদা: "function" হলো 1205 আর "tracing" হলো 1254। যে টিউনিং স্ক্রিপ্ট কেবল দেখে JIT চালু আছে কি না, সেটি নির্দ্বিধায় ভুল মোডটিই রেখে দেবে আর কাজ হয়ে গেছে বলে জানাবে।
aaPanel শিপ করে 1205। SixPanel শিপ করে tracing। তিনটি পর্যায়ক্রমিক জোড়ায় এক অনুরোধে 9-এর মধ্যে 9টি এন্ডপয়েন্টে এবং একসাথে চারটিতে 9-এর মধ্যে 9টিতে tracing এগিয়ে ছিল — জ্যামিতিক মাধ্যম 5.1% ও 6.2%।
এর যে-কোনো একটি পার্থক্য একা এই মেশিনগুলোর নয়েজের ভিতরেই পড়ে। কিন্তু আঠারোর মধ্যে আঠারোটি একই দিকে যাওয়া নয়েজ নয়।
বিশেষ করে 6amMart-এর জন্য tracing-ই সঠিক মোড: function JIT লক্ষ্য করে আঁটসাঁট সংখ্যাগত লুপ, যা একটি Laravel অনুরোধ চালায়ই না।
থাকা একটি PHP version পিছনে কিছু খরচ না — measured, assumed নাফারাকের 0%
রিলিজের নিজের আর্কাইভে যে PHP আছে, SixPanel সেটিই বসায় — Ubuntu 26.04-এ 8.5, Debian 13-এ 8.4, Ubuntu 24.04-এ 8.3 — কারণ ডিস্ট্রিবিউশনের নিজের প্যাকেজে থাকা মানে নিরাপত্তা আপডেট আপনাআপনি আসে, পরিবেশনের পথে কোনো তৃতীয় পক্ষের রিপোজিটরি না রেখে। স্পষ্ট আপত্তিটি হলো, নতুন PHP তো দ্রুততর।
aaPanel মেশিনে দুটি সংস্করণই বসানো, তাই সেটি প্রশ্নটির পরিষ্কার উত্তর দিতে পেরেছে। 8.3 পুলকে আগে পুরো 8.4-এর টিউনিং দেওয়া হয়েছিল — সেটি ডিফল্টে পড়ে ছিল, যা ফলাফলকে পক্ষপাতদুষ্ট করত — আর সেটিংগুলো ফাইল থেকে নয়, চলমান প্রসেস থেকে যাচাই করা হয়েছে।
তিনটি পর্যায়ক্রমিক জোড়া: 8.4-এর বিপরীতে 8.3-এর জ্যামিতিক মাধ্যম 0.9994। 7টির মধ্যে 3টি সারিতে 8.3 এগিয়ে ছিল, আর প্রতিটি পার্থক্যই অন্তত একটি পক্ষের নিজের রান-টু-রান বিস্তারের চেয়ে ছোট। ধীর অ্যাডমিন রিপোর্টও একই কথা বলেছে।
তাই SixPanel-কে ডিস্ট্রিবিউশনের নিজের প্যাকেজে রাখার নিয়মটি বিনামূল্যে — এতে গতির কোনো খরচ নেই। এড়ানোর মতো কোনো ছাদও নেই: 6amMart-এর composer.json 8.5-এর নিচে একটি সীমা ঘোষণা করে, কিন্তু সেটি ঘোষণা, মাপ নয় — আর সাদামাটা CodeCanyon ট্রি ও আমাদের নিজের ফর্ক, দুটিতেই কোডটি 8.5.4-এ চালিয়ে পাওয়া গেছে বাইট-হিসেবে অভিন্ন স্প্রেডশিট এক্সপোর্ট আর চালু হওয়া Laravel।
কি check করা হয়েছিল এবং কারণ found না করা হয়েছিলছয়টি candidate
প্রতিটি এটি একটি plausible ব্যাখ্যা যা কেউ অফার করতে পারে। প্রতিটি পরিমাপ করা এবং ruled out।
- Web server
- প্রতিটি এন্ডপয়েন্টের সময় মাপা হয়েছে নেটওয়ার্কের উপর দিয়ে, আর আবার একটিমাত্র PHP প্রসেসের ভিতরে, দুই মেশিনেই। পার্থক্য aaPanel-এ 0 থেকে 7 ms আর SixPanel-এ 3.5 থেকে 5 ms, যার বেশির ভাগই এনক্রিপশনের হ্যান্ডশেক। প্রতি অনুরোধে একটি অ্যাক্সেস লগ লেখা সত্ত্বেও aaPanel-এর অংশটি বড় নয়।
- Database
- Query time effectively একই সব configuration জুড়ে।
- PHP database কিভাবে reach করে
- উভয় local socket-এ, verify করা running process থেকে।
- Cache layer
- কনফিগারেশন ফাইল থেকে পড়া নয়, গুনে দেখা: aaPanel-এ প্রতি অনুরোধে 17.1টি ক্যাশ কমান্ড, SixPanel-এ 18.1টি। কোনোটিই চুপচাপ ডিস্কে ফিরে যাচ্ছে না।
- PHP-র compiled-code cache
- দুটিতেই শূন্য আউট-অফ-মেমরি ইভেন্ট, শূন্য হ্যাশ কলিশন আর শূন্য ম্যানুয়াল রিস্টার্ট। SixPanel-এ হিট রেট 99.86% আর অপচয় 0%।
- Hardware
- অভিন্ন প্রসেসর মডেল নিচে, enabled security mitigation সেট।
Slowest জিনিস 6amMart-এ server নয়, এবং কোনো panel এটি fix করতে পারে না। একটি single query দিয়ে যা সূচক ছাড়াই চলে.Application কোড
আসল 66,701 অর্ডারের ডেটাসেটে সব 297টি অ্যাডমিন পেজের সময় মাপা হয়েছে। এর মধ্যে 290টি 300 ms-এর কমে উত্তর দেয়। প্যানেল সার্বিকভাবে ধীর নয়।
সাতটি পেজেই পুরো সমস্যাটা। সবচেয়ে খারাপটি, দিন-ভিত্তিক লেনদেনের রিপোর্ট, নেয় 20.86 সেকেন্ড, যার 12.43 সেকেন্ড কাটে ডেটাবেস ড্রাইভারের ভিতরে — আর একটিমাত্র কোয়েরি 122 বার চলে, প্রতিবার 87.6 ms, অর্থাৎ একা সেটিই 10.7 সেকেন্ড।
পরীক্ষা করা প্রতিটি সার্ভারেই এটি আছে, আর চেষ্টা করা প্রতিটি সেটিং-এ এটি অটুট থেকেছে — পুরো aaPanel টিউনিং পাসসহ: আগে 20,925 ms, পরে 20,470 ms।
এটি 6amMart-এর নিজের কোড, তাই কোনো কন্ট্রোল প্যানেল এটি ঠিক করতে পারে না আর কারোরই তা দাবি করা উচিত নয়। অ্যাপ্লিকেশনটির বিপরীতে এটি পুরো লিখে রাখা আছে, আর আমাদের 6amMart ইনস্টলেশন সার্ভিস ঠিক এই ধরনের জিনিসের জন্যই আছে।
আমরা যা যা প্রকাশ করি
সব রিপোর্ট, এক জায়গায়
এই পাতার কোনো সংখ্যাই একা দাঁড়িয়ে নেই — প্রতিটি এসেছে প্রকাশিত কোনো রিপোর্ট থেকে, তার পদ্ধতি, সীমাবদ্ধতা আর আমাদের পক্ষে যায়নি এমন ফলাফলসহ। কেনার আগে পড়ে নিন; সেজন্যই এগুলো রাখা।
SixPanel বনাম aaPanel
একটি রিকোয়েস্টে 1.76× দ্রুত, একসঙ্গে চারটি এলে 1.82× — পুরোদস্তুর টিউন করা aaPanel-এর বিপক্ষে; কারণগুলো ভাগ করে দেখানো, আর ব্যবধানের 32% সৎভাবেই "ব্যাখ্যাতীত" বলে চিহ্নিত।
SixPanel বনাম SixPanel Docker বনাম aaPanel
একই হার্ডওয়্যারে তিনটি প্যানেল আর বাইট-অবধি অভিন্ন একটি দোকান — শিরোনামের সংখ্যাগুলোর পেছনের পূর্ণ পদ্ধতি।
SixPanel বনাম CloudPanel
একটি ন্যায্য তুলনা: CloudPanel ভালো সর্বজনীন সফটওয়্যার। প্রশ্ন হলো, আপনি কোন সমস্যাটা সমাধান করছেন।
SixPanel বনাম সাদামাটা সার্ভার
বেশিরভাগ মালিক যে হাতে-গড়া সার্ভার দিয়ে শুরু করেন, তার ওপরে প্যানেল কী যোগ করে — আর বছর ঘুরলে সেটার দাম কী দাঁড়ায়।
কোন অপারেটিং সিস্টেম
Ubuntu 26.04 বনাম Ubuntu 24.04 বনাম Debian 13, মেপে দেখা: গতিতে সমানে-সমান, সাপোর্টের মেয়াদে নয়।
কোন ডেটাবেস ইঞ্জিন
বাস্তব একটি দোকানের সামনে পাঁচটি ইঞ্জিন। পুরো অ্যাপ্লিকেশনে MariaDB 11.8 আর 10.11 সমানে-সমান; দুটি MySQL-ই কোড অপরিবর্তিত রেখে সেটি চালাতে পারে না।
অপটিমাইজড 6amMart — মাপা ফলাফল
22× দ্রুত হওয়া ফিচারড স্ট্রিপ, 297 পাতার অ্যাডমিন ঝাড়াই, 17.5 সেকেন্ডের রিপোর্ট নেমে এসেছে 0.7-এ — আর ইচ্ছে করেই ধীর রেখে দেওয়া দুটি পাতা, জয়গুলোর পাশেই প্রকাশিত।
স্কেল টেস্ট
66,701টি বাস্তব অর্ডার, 113,231টি অর্ডার লাইন — যে ডেটাসেটে নীরব ত্রুটিগুলো ধরা পড়েছিল।
সারানো ত্রুটিগুলো
যেগুলো কোনো এরর না দেখিয়েই টাকা খরচ করাচ্ছিল — কুপন, ঘড়ি, স্টক, ডাবল পেমেন্ট।
যা এখনও অমীমাংসিত
যে পাতাটি বাকি চারটিকে পড়ার যোগ্য করে তোলে: যা আমরা এখনও সমাধান করিনি, সোজাসাপ্টা লেখা।
চেঞ্জলগ
প্রতিটি রিলিজ — ভুলগুলোসহ, আর সেগুলো আমাদের কী শেখাল তাও।
আপনি আসলে কী পান
একজন ক্রেতা কাজটি নিয়ে যেভাবে ভাবেন, সেভাবে সাজানো
দুটি বিষয়ের সাথে স্পষ্ট শর্ত আছে। পুরোনো সার্ভার থেকে সরিয়ে আনা আর একই মেশিনে রিস্টোর — 15 আগস্টের রাউন্ডে এই দুটি কেবল পড়ে যাচাই করা হয়েছে, চালানো হয়নি। নিচে সেগুলো চিহ্নিত করা আছে। বাকি সবকিছু হয় চালিয়ে দেখা হয়েছে, নয়তো শিপ করা ও পরীক্ষা করা যায় এমন একটি সারফেস — তবে সৎ বাক্যটি হলো “এটি শিপ হয়”, “এটি আপনার ধরনের সার্ভারে প্রমাণিত” নয়।
চালু করা
ভাড়া করা সার্ভার থেকে প্যানেল লগইন পর্যন্ত, হাতে বানানো স্ট্যাক ছাড়াই।
- একটি কমান্ড। ইনস্টল কমান্ডটি নামানো হয়, প্রকাশিত একটি ফিঙ্গারপ্রিন্টের সাথে মিলিয়ে দেখা হয়, তারপরই কেবল চলে। ফিঙ্গারপ্রিন্ট না মিললে কমান্ড থেমে যায় আর কিছুই ইনস্টল হয় না।
- যে সার্ভারে এটি চলতে পারবে না, কিছু নামানোর আগেই সেটিকে নাম ধরে ফিরিয়ে দেয়: ভুল অপারেটিং সিস্টেম, ভুল প্রসেসর টাইপ, খুব কম মেমরি, আগে থেকেই আরেকটি কন্ট্রোল প্যানেল আছে, কিংবা 80 বা 443 পোর্ট কেউ ব্যবহার করছে।
- প্রথম লগইনে একটি সেটআপ উইজার্ড: বেসিক → পাসওয়ার্ড → ডোমেইন → SSL → অ্যাপ → ব্যাকআপ।
- ইনস্টলের সময় Autotune, আর পরে চাইলেই আবার। এটি আসল মেশিন দেখে ডেটাবেস, ক্যাশ ও PHP ওয়ার্কারের মাপ ঠিক করে।
- 2টি কোর ও 4 GB-তে একটি পুরো দোকান চালায়।
- পড়ে যাচাই করা, চালানো নয়: কিংবা চলতি একটি দোকান সরিয়ে আনুন। SixPanel SSH দিয়ে পুরোনো সার্ভার থেকে একটি লাইভ ইনস্টল টেনে আনতে পারে — সেটিংস ফাইল, আপলোড, আর পাইপ করে পাঠানো একটি ডেটাবেস ডাম্প। 15 আগস্টের রাউন্ডে এটি চালানো হয়নি, কেবল পড়ে যাচাই করা হয়েছে। এর উপর নির্ভর করার আগে একটি অতিরিক্ত সার্ভারে চালিয়ে দেখুন, আর তা না করা পর্যন্ত পুরোনো মেশিনটি রেখে দিন।
কেন জরুরি: প্রথম দিনেই বেশিরভাগ দোকান একটা সপ্তাহ হারিয়ে ফেলে — এখানে দিনটা শেষ হয় একটি চালু পেজ দিয়ে।
আপনার ডোমেইন ও HTTPS
আসল সার্টিফিকেট, আপনার হয়ে নবায়ন, আর Cloudflare ঠিকভাবে সামলানো।
- ফ্রি Let's Encrypt সার্টিফিকেট, একটি দৈনিক কাজ দিয়ে স্বয়ংক্রিয়ভাবে নবায়ন করা হয়।
- প্রতি দোকানে, প্রতি লক্ষ্যে (অ্যাডমিন, স্টোরফ্রন্ট, ওয়েবসকেট) একাধিক ডোমেইন, প্রতিটির নিজস্ব primary, SSL ও Cloudflare ফ্ল্যাগসহ।
- Cloudflare-সচেতন। এটি প্রথমে Cloudflare প্রক্সির মধ্য দিয়ে একটি আসল Let's Encrypt সার্টিফিকেট নেওয়ার চেষ্টা করে, যা Full (strict)-এ কাজ করে। সেটি না হলে এটি 10 বছরের একটি সেলফ-সাইনড অরিজিন সার্টিফিকেটে নামে, যার জন্য Full দরকার। এটি Cloudflare-এর IP রেঞ্জ নিয়ে আসে, যাতে আপনার লগে Cloudflare-এর নয়, দর্শকের আসল ঠিকানা দেখা যায়।
- একটি Cloudflare টোকেন, আর প্যানেল আপনার হয়ে Cloudflare-এর একগুচ্ছ অপশন সামলায়। প্রতিটি বিষয়ে কাঙ্ক্ষিত-বনাম-চালু অবস্থা দেখায়, আর push বা pull সিঙ্ক দেয়। আপনার নিজের নিয়মগুলো লেখার পরেও টিকে থাকে।
- একটি ফায়ারওয়াল পেজ, যা আপনার সার্ভারের জন্য ঠিক নিয়মগুলো ছাপে, সাথে Cloudflare-এর দুটি রেঞ্জ তালিকা আর সেগুলো মিলিয়ে দেখার কমান্ড। প্যানেল নিজে কখনো আপনার প্রোভাইডারের ফায়ারওয়ালে হাত দেয় না।
কেন জরুরি: HTTPS বিভ্রাটই চিরচেনা নীরব ঘাতক — শনিবারে মেয়াদ ফুরানো একটি সার্টিফিকেট দোকানটাকেও সঙ্গে নিয়ে ডোবে।
কোডের পরিবর্তন পাঠানো
দুই ধরনের আপডেট, যা কখনোই একটির সাথে অন্যটি মিলিয়ে ফেলা হয় না।
- Push করলেই ডিপ্লয়। আপনার git হোস্ট থেকে আসা একটি সাইন করা webhook ডিপ্লয় শুরু করে।
- Deploys → Update আপনার 6amMart কোড বদলায়। Settings → self-update SixPanel বদলায়। কোনোটিই আপনার সেটিংস ফাইল, আপনার data/ ফোল্ডার বা আপনার ডেটাবেসে হাত দেয় না।
- ইতিহাস ও রোলব্যাক, শেষ 30টি ডিপ্লয় রেখে দেওয়া হয়।
- একটি ক্লিন-ট্রি গার্ড। আপনি সার্ভারে ফাইল সম্পাদনা করে থাকলে আপডেট আপনার কাজ মুছে না দিয়ে থেমে যায় এবং ফাইলগুলোর নাম বলে দেয়।
কেন জরুরি: দোকান চালানোর সবচেয়ে ঝুঁকিপূর্ণ মিনিটগুলো আসে "deploy" চাপার ঠিক পরে — এটি সেগুলোকে নিরুত্তাপ করে দেয়।
কিছু না হারানো
নির্ধারিত সময়ে, ইনক্রিমেন্টাল, আর ধরে নেওয়ার বদলে সপ্তাহে একবার প্রমাণিত।
- ইনক্রিমেন্টাল ব্যাকআপ (restic), নির্ধারিত সময়ে, রিটেনশনসহ।
- চারটি গন্তব্য: একই সার্ভার, S3, SFTP, বা Google Drive।
- সাপ্তাহিক স্বয়ংক্রিয় রিস্টোর টেস্ট একটি ফেলে দেওয়া ডেটাবেসে — আপনার লাইভ ডেটায় কখনো হাত পড়ে না, আর ফলাফল Backups পেজ ও Health পেজ দুটিতেই দেখা যায়।
- একটি ব্যাকআপে থাকে প্রতিটি প্রকল্পের ডেটাবেস, আপলোড করা ফাইল, আর অ্যাপ্লিকেশন সেটিংস ফাইল। এতে আপনার কোড থাকে না — সেটি git থেকে ফিরে আসে।
- একটিই শেয়ার করা ব্যাকআপ পাসওয়ার্ড, একবার তৈরি হয়ে প্যানেলের স্টেটে রাখা থাকে। এটি হারালে কোনো ব্যাকআপই আর কখনো খোলা যাবে না।
- পড়ে যাচাই করা, চালানো নয়: 15 আগস্টের রাউন্ডে রিস্টোর পড়ে যাচাই করা হয়েছে, চালানো হয়নি। নিচের দুটি রিস্টোর সীমাবদ্ধতাও দেখুন — সেগুলোর কারণেই এটি গুরুত্বপূর্ণ।
কেন জরুরি: কখনও না খোলা ব্যাকআপ একটা আশা মাত্র, ব্যাকআপ নয়। সাপ্তাহিক রিস্টোর টেস্টই তফাতটা গড়ে দেয়।
সিসঅ্যাডমিন না হয়েও প্রতিদিন চালানো
প্যানেল সমস্যাটির নাম বলে আর আপনাকে বোতামটি দেয়।
- হেলথ পেজ: প্রায় 20টি পরীক্ষা, মনোযোগ দরকার / সুস্থ / তথ্য — এই তিন ভাগে সাজানো, প্রতিটির সাথে পরিণামের একটি বাক্য ও একটি ফিক্স বোতাম। প্রতিটি পরীক্ষার সীমা 2 সেকেন্ড আর পুরো পেজের 10 সেকেন্ড, তাই আটকে যাওয়া একটি পরীক্ষা পুরো পেজ আটকাতে পারে না।
- ওই সংখ্যাটি নিয়ে তিনটি উৎস একমত নয়। শিপ করা ম্যানুয়ালে লেখা “বিশটির বেশি”, কোড ইনভেন্টরিতে গোনা যায় প্রায় 20টি পরীক্ষা, আর একটি পুরোনো পেজ স্পেকে লেখা প্রায় পনেরো। এই পেজ ছাপে প্রায় 20 — শিপ করা প্রোডাক্টে ভিত্তি আছে এমন দুটি সংখ্যার মধ্যে কমটি।
- একটি watchdog যা service পুনরায় শুরু করে যা চলছে কিন্তু কাজ করছে না। একটি প্রক্রিয়া সুপারভাইজর কিছু পুনরায় শুরু করবে না যা জীবন্ত এবং ভাঙ্গা, কারণ কিছু crash করেনি। SixPanel-র নিজস্ব loop করে, এবং এর checks test করে কাজ করছে কিনা বরং প্রক্রিয়া বিদ্যমান কিনা।
- একটি জব ইঞ্জিন। একসাথে একটিই দীর্ঘ কাজ, বাকিগুলো সারিতে অপেক্ষা করে। লগ সরাসরি ব্রাউজারে আসে। শেষ 20টি কাজ রাখা হয়, প্রতিটিতে 2,000 লাইন।
- আপনার অ্যাপের জন্য একটি সেটিংস-ফাইল এডিটর, যা আপনার কমেন্ট, আপনার ক্রম ও সম্পর্কহীন লাইনগুলো রেখে দেয়, প্রতিটি কি-র জন্য ঠিক ধরনের ইনপুট দেয়, আর স্ট্যাকের নিজের কি-গুলো রিড-অনলি হিসেবে চিহ্নিত করে।
- একটি ফাইল ম্যানেজার, যা ঠিক দুটি ফোল্ডারে আটকানো: আপনার অ্যাডমিন কোড আর আপনার স্টোরফ্রন্ট কোড।
- চাইলে phpMyAdmin — Database পেজ থেকে চালু ও বন্ধ করা হয়, কখনো চালু ফেলে রাখা হয় না।
- স্লো-কোয়েরি সংগ্রহ, যা আপনি Database পেজ থেকে চালু ও পরিষ্কার করতে পারেন।
- সার্ভারে একটি sixpanel কমান্ড, সাথে একটি ম্যানুয়াল পেজ, একটি চিট শিট, একটি নম্বরযুক্ত মেনু, একটি did-you-mean মিলকারী আর শেল কমপ্লিশন।
- প্যানেলের ভেতরেই পুরো গ্রাহক ম্যানুয়াল, একই লগইনের পেছনে — 24টি কাজের পেজ।
- এক কমান্ডে একটি সাপোর্ট বান্ডল। এটি ভার্সন, হেলথের ফল, সার্ভিসের অবস্থা, ডিস্ক ব্যবহার আর প্রতিটি লগের শেষ 500 লাইন জড়ো করে। লেখার আগেই আপনার সেটিংস ফাইল কেবল কি-র নামে নামিয়ে আনা হয়, প্যানেলের নিজের স্টেট ফাইল একেবারেই নেওয়া হয় না, আর আপনার প্যানেল লিঙ্কের গোপন কোড ও পাসওয়ার্ডের মতো দেখতে সাধারণ মানগুলো ঢেকে দেওয়া হয়।
কেন জরুরি: যে প্যানেল আপনি সত্যিই রোজ খোলেন, তার উচিত "সব ঠিক আছে তো?" প্রশ্নের উত্তর এক নজরে দেওয়া — এক ঘণ্টায় নয়।
অন্যদের ঢুকতে দেওয়া
পাসওয়ার্ড হাতে তুলে না দিয়ে সময়-সীমিত অ্যাক্সেস।
- ডেভেলপারের জন্য অস্থায়ী লগইন: নিজের নাম ও পাসওয়ার্ড, 1 ঘণ্টা, 8 ঘণ্টা, 24 ঘণ্টা বা 7 দিন পরে মেয়াদ শেষ, একসাথে সর্বোচ্চ 20টি চালু। পাসওয়ার্ড ঠিক একবারই দেখানো হয়। তাঁরা সাইটটি চালাতে পারেন। কে ঢুকতে পারবে তা বদলাতে পারেন না, আর আপনার গোপন তথ্যও পড়তে পারেন না।
- কাউকে প্যানেল দেখানোর জন্য একটি রিড-অনলি ডেমো লগইন। দুই ঘণ্টার সেশন, প্রতিটি লেখা প্রত্যাখ্যাত, স্পর্শকাতর মান ঢাকা।
- একটি অ্যাক্টিভিটি লগ, আর চালু সেশনের একটি তালিকা, যা আপনি একটি একটি করে বা একসাথে বাতিল করতে পারেন।
- পড়ে যাচাই করা, চালানো নয়: অ্যাক্টিভিটি লগ সবকিছু ঢাকে না। একটি নির্ধারিত কাজ তৈরি, সম্পাদনা ও হাতে চালানো — সবই লেখা হয়, কিন্তু একটি মুছে ফেললে কোনো অডিট রেকর্ডই লেখা হয় না।
কেন জরুরি: প্যানেলে বেশিরভাগ হানাদারি মোটেই চতুর কিছু নয় — দৃশ্যমান লগইন পেজে আন্দাজে মেলানো পাসওয়ার্ড মাত্র। এই লগইন পেজটা দৃশ্যমানই নয়।
এক সার্ভারে একাধিক দোকান
প্রথা দিয়ে নয়, গঠন দিয়েই আলাদা করা।
- প্রতিটি project এর নিজস্ব unix user, নিজস্ব ডেটাবেস এবং ডেটাবেস user, নিজস্ব application folder, নিজস্ব site configuration এবং নিজস্ব socket-এ নিজস্ব cache instance পায় — তাই এক দোকান অন্যের cache করা secrets পড়তে পারে না, এবং এক থেকে cache সাফ অন্য খালি করতে পারে না।
- দুটি প্রকল্প একই ডেটাবেস ভাগ করতে পারে না: নামটি একটি যাচাই করা, অনন্য slug থেকে তৈরি হয়।
- প্রতিটি বাড়তি দোকানের জন্য মোটামুটি 2 GB বেশি RAM আর 1–2টি বেশি কোর ধরে রাখুন — 2টি কোর, অর্থাৎ ওই পরিসরের উপরের দিকটাই ধরুন, কারণ কম বরাদ্দ দেওয়াই দামি ভুল।
কেন জরুরি: এজেন্সির দ্বিতীয় দোকানের পক্ষে প্রথমটির ডেটা পড়া তত্ত্বগতভাবেও সম্ভব হওয়া উচিত নয় — এখানে সেটা কার্নেল-স্তরে বলবৎ, আর আমরা নিজেরাই আক্রমণ চালিয়ে যাচাই করেছি।
গতি, যা আগে থেকেই কনফিগার করা
আপনার নিজের মেশিনে ওয়েব সার্ভারে একটি পাঁচ সেকেন্ড micro-cache, 6amMart-র নিজস্ব অনুরোধ প্যাটার্নের চারপাশে গঠিত।
- সর্বজনীন ক্যাটালগ এন্ডপয়েন্টের একটি নির্দিষ্ট তালিকার উপর nginx-এ পাঁচ সেকেন্ডের একটি ক্যাশ। একটি পাঁচ-সেকেন্ডের উইন্ডোর মধ্যে config এন্ডপয়েন্টে 100টি অনুরোধ এলে ক্যাশ সেগুলোকে 100টির বদলে একটি PHP শুরুতে পরিণত করে — এটি ক্যাশ উইন্ডো থেকে পাটিগণিত, মাপা throughput ফলাফল নয়। স্টোরেজ 64 MB-তে সীমিত, 60-সেকেন্ড নিষ্ক্রিয় থাকলে সরিয়ে দেওয়া হয়।
- এখানে এটি কেন বিশেষভাবে জরুরি: স্টোরফ্রন্ট সার্ভারে রেন্ডার হয়, তাই ক্রেতার প্রতিটি পেজ একই মেশিনে ফিরে আসা কয়েকটি API কল হয়ে দাঁড়ায়, আর মোবাইল অ্যাপের প্রতিটি কোল্ড স্টার্ট আরও 15–20টি API কল।
- এটি কখনো ব্যক্তিগত বা সাইন-ইন করা রেসপন্স পরিবেশন করে না। যেকোনো Authorization হেডার থাকলে এটি এড়িয়ে যায়। যেকোনো কুকি থাকলেই এড়িয়ে যায়। Set-Cookie বহন করে এমন কোনো রেসপন্স nginx জমা রাখতে অস্বীকার করে। একটি আলাদা ডিনাই তালিকা অ্যাডমিন, ভেন্ডর প্যানেল, লগইন, চেকআউট, কার্ট, অর্ডার ও পেমেন্ট কলব্যাক ঢাকে।
- জোন, মডিউল ও ভাষা ক্যাশ কি-র অংশ, তাই এক শহরের স্টোর কখনোই অন্য শহরে দেখানো যাবে না।
- PHP না চললেও এটি দোকান চালু রাখে। PHP পুল আটকে গেলে nginx সামান্য পুরোনো কপিটি দেখায় আর ব্যাকগ্রাউন্ডে নতুন করে আনে — 502 এররের দেয়ালের বদলে একটি চালু স্টোরফ্রন্ট।
- সবকিছু অন্যথায় hardware অনুসরণ করে: ডেটাবেস, PHP-র compiled-code cache, cache মেমরি এবং ওয়েব-সার্ভার buffers সব autotune দ্বারা প্রকৃত মেশিন থেকে সঠিক।
- বাস্তব নেটওয়ার্কের জন্য মাপা রিকোয়েস্ট-হারের স্তর। লগইন, OTP ও পাসওয়ার্ড রিসেটে কড়া সীমা; সাধারণ ব্রাউজিংয়ে আলগা; সার্চের জন্য আর কার্ট ও অর্ডার লেখার জন্য আলাদা। ডকুমেন্টেশন এটিকে যা তা-ই বলে — একটি ফ্লাড শিল্ড, DDoS সুরক্ষা নয় — কারণ পুরো একটি শহর যখন একটি ক্যারিয়ার IP ঠিকানা ভাগ করে, তখন প্রতি-ঠিকানার সীমা নিখুঁত হতে পারে না।
- এই সাইটে “এজ” মানে Cloudflare, যেটিই আসল এজ স্তর। এই ক্যাশ সেটি নয়, আর সেভাবে ডাকাও হয় না।
কেন জরুরি: গতিই একমাত্র জিনিস, যা ক্রেতা প্রতিটি ভিজিটে টের পান — আর সে কারণেই এই সংখ্যাগুলো পদ্ধতিসহ প্রকাশ করা।
ঐচ্ছিক অংশ
দোকানের দরকার হলে চালু করুন।
- ওয়েবসকেটে (Reverb) লাইভ অর্ডার ট্র্যাকিং।
- ঐচ্ছিক Next.js কাস্টমার ওয়েবসাইট, যার স্ট্যাটিক অ্যাসেট immutable হিসেবে পরিবেশিত হয়।
- ওয়েবসাইট ছাড়া শুধু মোবাইল অ্যাপে বিক্রি করাও একটি সমর্থিত রূপ।
কেন জরুরি: কালেভদ্রে দরকার পড়া টুলের অলস বসে থাকার কোনো খরচ থাকা উচিত নয় — এগুলো দরকারে চালু হয়, তারপর পথ ছেড়ে সরে যায়।
Shop check-up (SixPreflight, অন্তর্ভুক্ত)
SixPanel যে সার্ভার দেখে, তার বদলে এটি আপনার দোকানের ভেতরের সেটিংস পরীক্ষা করে।
- SixPreflight প্যানেলের সাথেই আসে এবং Shop check-up পেজ হিসেবে ভেতরে বসানো থাকে। এতে আছে প্রায় 134টি পরীক্ষা, একটি ওয়েটেড স্কোর আর একটি লেটার গ্রেড।
- কেন 134, আরও বড় সংখ্যা নয়: ভেতরের তিনটি উৎস তিন রকম উত্তর দেয়। কোডে অনন্য স্ক্যান চেক কি সরাসরি গুনলে হয় 163; ইঞ্জিনিয়ারিং হ্যান্ডওভারে লেখা 134–136 এবং দুটির মধ্যে কমটি ব্যবহার করতে বলা আছে; একটি পুরোনো পেজ স্পেকে লেখা প্রায় 100। এই পেজ ছাপে ~134, চলতি কোনো উৎস যে সংখ্যাটির পক্ষে দাঁড়াতে পারে তার মধ্যে সবচেয়ে কমটি।
- SixPanel-এর ভেতরে চললে এটি ইচ্ছে করেই আচরণ বদলায়: প্যানেল যেসব স্তরের মালিক, সেগুলোর কপি-পেস্ট কনফিগ ব্লক আর দেখানো হয় না, আর আপনার দোকানের নিজের অ্যাডমিন প্যানেলের সেটিংসগুলো সার্ভার থেকে আলাদাভাবে স্কোর করা হয়।
কেন জরুরি: সার্ভার নিখুঁত থেকেও দোকানের ভেতরের একটা ভুল সেটিং চুপিচুপি অর্ডার খোয়াতে পারে — সেগুলো পড়ে দেখার জন্যই দ্বিতীয় জোড়া চোখ।
যা নিজে থেকে চলে
অটোমেশনের পুরো নকশা
"অটোমেটেড" শব্দটা ছাপিয়ে দেওয়া সহজ। এখানে রয়েছে প্যানেল আপনাকে ছাড়াই যে কাজগুলো চালায় তার প্রতিটি — কোনটা কিসে চালু হয়, আর এটা না থাকলে মাঝরাতে কোন কাজটা আপনাকে হাতে করতে হতো।
- একবার, শুরুতে
একটি কমান্ডে পুরো সার্ভার
নতুন একটি Ubuntu সার্ভারে একবার পেস্ট করলেই ইনস্টল হয়ে যায় ওয়েব সার্ভার, ডেটাবেস, PHP, ক্যাশ, কিউ ওয়ার্কার, শিডিউলার, ওয়েবসকেট সার্ভার আর খোদ প্যানেল — প্রতিটিই যে মেশিনে বসছে তার মাপে। আপনি শুধু একটা ডোমেইন লেখেন; বাকি সব নিজে থেকেই বসে, কনফিগার হয় আর চালু হয়।
- প্রতিটি মেয়াদ ফুরানোর আগে
নিজে নিজে রিনিউ হওয়া HTTPS
সার্টিফিকেট ইস্যু হয় স্বয়ংক্রিয়ভাবে — ডোমেইন Cloudflare-এ থাকলে DNS-ভিত্তিক, তাই ইন্টারনেট সার্ভারে পৌঁছানোর আগেই সেগুলো কাজ করে — আর প্রতিটি রিনিউয়ালে ওয়েব সার্ভার রিলোড হয় সার্টিফিকেট-প্রতি আলাদা হুকের মাধ্যমে, ফলে একটি নষ্ট সার্টিফিকেট বাকিগুলোকে কখনও আটকে রাখতে পারে না।
- আপনার শিডিউলে
ব্যাকআপ, যা সত্যিই চলে
আপনার ঠিক করা শিডিউলে ইনক্রিমেন্টাল ব্যাকআপ — একই সার্ভারে, S3, SFTP বা Google Drive-এ, প্রতিটি রানের পর রিটেনশন প্রয়োগসহ। প্রতিটি প্রজেক্টের ডেটাবেস, আপলোড করা ফাইল আর সেটিংস — কোড ফিরে আসে git থেকে।
- প্রতি সপ্তাহে
সাকসেস মেসেজ নয়, রিস্টোর টেস্ট
সপ্তাহে একবার প্যানেল সর্বশেষ ব্যাকআপটি একটি অস্থায়ী ডেটাবেসে রিস্টোর করে রো গুনে দেখে। যে ব্যাকআপ আসলে খোলাই যায় না, সেটি Health পেজ লাল করে দেয় — কারণ সাকসেস মেসেজ কোনো প্রমাণ নয়।
- কয়েক মিনিট পরপর
নীরব বিভ্রাটের জন্য সেলফ-হিলিং
ওয়াচডগ এমন সার্ভিস রিস্টার্ট করে যেটা চলছে ঠিকই, কিন্তু ভেঙে আছে — সাধারণ সুপারভাইজার এই কেসটা পুরোপুরি মিস করে, কারণ কিছুই তো ক্র্যাশ করেনি। ওয়াচডগের করা প্রতিটি রিস্টার্ট কারণসহ অ্যাক্টিভিটি লগে উঠে যায়।
- ইনস্টল ও আপডেটে
মেশিনের মাপে টিউনিং
ডেটাবেসের buffer pool, ক্যাশ মেমোরি, টেম্পোরারি-টেবিলের আকার আর PHP ওয়ার্কার হিসাব করা হয় মেশিনের প্রকৃত মেমোরি আর কোর থেকে — একটাই সাইজিং সিঁড়ি, 36 রকম সার্ভার-আকৃতিতে মেপে দেখা, ইনস্টলার আর প্যানেল দুটোই হুবহু একইভাবে প্রয়োগ করে।
- প্রতি রাতে
ডেটাবেসের নিয়মিত ঝাড়পোঁছ
প্রতি রাতের একটি সুইপ সেই মেয়াদোত্তীর্ণ রোগুলো মুছে দেয়, যেগুলো অ্যাপ্লিকেশন নিজে কখনও ডিলিট করে না; আর রবিবারে টেবিলগুলো অপটিমাইজ হয় — কেবল তখনই যখন ডিস্কে যথেষ্ট জায়গা থাকে, এবং প্রতিটি ফলাফল অনুমান করে নয়, যাচাই করে দেখে।
- প্রতিটি ডিপ্লয়ে
মাপা ইনডেক্স, জায়গামতো রাখা
একগুচ্ছ ডেটাবেস ইনডেক্স — প্রতিটিই 66,701 অর্ডারের একটি বাস্তব দোকানে মেপে দেখার পরই তালিকায় ঢুকেছে — প্রতিটি কোড বদলের পর যাচাই করে আবার প্রয়োগ করা হয়। যাচাই হয় ইনডেক্সটি কী কভার করে তা দিয়ে, নাম দিয়ে নয় — তাই নাম বদলানো ইনডেক্স একে ফাঁকি দিতে পারে না।
- প্রতিটি git push-এ
Push-to-deploy, শুরু থেকে শেষ
আপনার রিপোজিটরিতে push করুন, দোকান নিজেই আপডেট হয়ে যায়: pull, ডিপেন্ডেন্সি, ডেটাবেস মাইগ্রেশন, config cache নতুন করে তৈরি — তবে কেবল সেখানেই, যেখানে আপনার কোডের জন্য সেটা মেপে নিরাপদ প্রমাণিত — আর একটিও রিকোয়েস্ট না ফেলে PHP রিলোড। আগের রিলিজটি ধরা থাকে একটি রোলব্যাক বাটনে।
- সারাক্ষণ
যে হেলথ চেক সমাধানটাও বলে দেয়
ত্রিশের বেশি চেক চলে যার যার নিজস্ব শিডিউলে — সার্ভিস, ডিস্ক, সার্টিফিকেট, DNS, Cloudflare, এমনকি প্যানেলের নিজের ফাইলগুলোও মিলিয়ে দেখা হয় যে রিলিজে সেগুলো এসেছিল তার সঙ্গে। ব্যর্থ একটি রো শুধু সমস্যাটি নয়, ঠিক কোন সমাধানে সারবে সেটাও নাম ধরে বলে দেয়।
- যখন আপনাকে দরকার
ইনবক্সের কদর বোঝে এমন ইমেইল
প্রতিটি সমস্যার জন্য ছয় ঘণ্টায় বড়জোর একটি ইমেইল, ইনবক্স প্রিভিউ থেকেই পড়া যায় এমন রঙিন রায়সহ — আর সমস্যা মিটে গেলে সবুজ "resolved", যাতে নীরবতার মানে আন্দাজ করতে না হয়।
- বাটন চাপলে
এক বাটনে, সিগনেচার-যাচাই করা আপডেট
একটি বাটন রিলিজ নামায়, আপনার সার্ভারে পিন করা কী-এর সঙ্গে তার সিগনেচার মিলিয়ে দেখে — ডাউনলোড হোস্ট বদলে দিলেও আপনার মেশিনের কী বদলানো যায় না — তারপর সেটি প্রয়োগ করে, আর সার্ভিসগুলো রিস্টার্ট করে এমন এক মাপা ক্রমে, যাতে দোকান চালু থাকে।
এই সবকিছুর পেছনে একটাই ধরন: প্যানেল কাজটা করে, কী করল লিখে রাখে, আর নিজের ফলাফল নিজেই যাচাই করে — এবং যা যাচাই করতে পারে না, তা দাবি না করে জানিয়ে দেয়।
ভেতরের কারিগরি
উন্নত প্রযুক্তি, নিজে থেকেই চলে
এর কোনওটাই ফিচার তালিকার একটা টিকচিহ্ন নয়। প্রতিটি হল মাপা আচরণ, কঠোর নিরাপত্তা-নিয়ম আর পড়ার মতো রিপোর্টসহ আসল যন্ত্র।
স্বয়ং-সারাই সুপারভাইজার
৬০ সেকেন্ডের একটি লুপ লাইভ দোকান যেসব কারণে ভাঙে তা-ই সারায়: আটকে থাকা কিউ, মেয়াদোত্তীর্ণ সার্টিফিকেট, ভুলে রেখে দেওয়া রক্ষণাবেক্ষণ মোড। কঠোর নিয়মে বাঁধা — আপনি যা থামিয়েছেন তা কখনও চালু করে না, আর ডিপ্লয় বা ব্যাকআপ চলাকালে কিছুই করে না।
ইনক্রিমেন্টাল, এনক্রিপ্টেড ব্যাকআপ
restic-এর ওপর তৈরি: প্রতিবার আগেরবারের পর যা নতুন বা বদলেছে শুধু তা-ই জমা হয় — ডেডুপ্লিকেটেড ও এনক্রিপ্টেড। দৈনিক ব্যাকআপ দ্রুত ও ছোট থাকে, অথচ প্রতিটি স্ন্যাপশট পুরোপুরি রিস্টোর হয়। গন্তব্য: লোকাল ডিস্ক, S3, SFTP, Google Drive।
ব্যাকআপ প্রমাণিত, অনুমান নয়
সবুজ ব্যাকআপ জব কোনও প্রমাণ নয়। নির্ধারিত ভেরিফাই সর্বশেষ স্ন্যাপশট খুলে দেখে আপনার ডাটাবেস ডাম্প সত্যিই ভেতরে আছে কি না — ফিরিয়ে আনতে পারব কি না, তার সৎ উত্তর আসে আর্টিফ্যাক্ট থেকে, এক্সিট কোড থেকে নয়।
আপনার সার্ভারে স্বয়ংক্রিয় টিউনিং
একটি মাপা সাইজিং সিঁড়ি আপনার মেশিনের RAM ও CPU থেকে ডাটাবেস বাফার পুল, Redis মেমরি আর PHP ওয়ার্কার সংখ্যা হিসাব করে — ইনস্টলের সময়, আবার রিসাইজে। ইনস্টলার আর প্যানেল একই সংজ্ঞা ভাগ করে, বিল্ড গেট তা ধরে রাখে।
প্রমাণিত নিরাপদ মাইক্রো-ক্যাশ
ব্যস্ত API এন্ডপয়েন্ট nginx ক্যাশ থেকে উত্তর দেয় — মাপা ১৬.৯ মিলিসেকেন্ড থেকে ০.৬ — তবে কেবল সেসব এন্ডপয়েন্ট ঢোকে যা কলকারী-নিরপেক্ষ প্রমাণিত: স্ট্যাটিক গেট অ্যাপের হ্যান্ডলার পড়ে আর তিন-বাহু লাইভ পরীক্ষা নিশ্চিত করে কোনও ক্রেতা অন্যের ডাটা কখনও দেখবে না।
প্রতিটি প্রকল্প সম্পূর্ণ আলাদা
প্রতিটি দোকান পায় নিজস্ব unix ইউজার, নিজস্ব PHP-FPM পুল আর পাসওয়ার্ড-সুরক্ষিত নিজস্ব Redis ইনস্ট্যান্স; ওয়ার্কারগুলো চলে systemd স্যান্ডবক্সে — রিড-অনলি সিস্টেম, প্রিভিলেজ এসকালেশন নেই। একটি প্রকল্প হ্যাকড হলেও অন্যটি পড়তে পারে না।
ক্রিপ্টোগ্রাফিকালি স্বাক্ষরিত আপডেট
প্রতিটি রিলিজে থাকে মেয়াদসহ ed25519-স্বাক্ষরিত ম্যানিফেস্ট। স্বাক্ষরহীন, বাসি বা ভুল চাবিতে স্বাক্ষরিত যেকোনও কিছু প্যানেল প্রত্যাখ্যান করে — আর বদলানো চাবিকে আগে রিলিজের বিরুদ্ধে নিজেকে প্রমাণ করতে হয়।
কাজ করার আগে আপনার অ্যাপ পড়ে
প্যানেল অন্ধভাবে কিছু ধরে নেয় না। কনফিগ ক্যাশিংয়ের সিদ্ধান্ত হয় আপনার নিজের 6amMart-এর কোড পড়ে — তাই রানটাইমে সেটিংস পড়া বিল্ড কখনও নিঃশব্দে ভাঙে না। অপরিবর্তিত CodeCanyon কোড আর অপ্টিমাইজড বিল্ড দুটোই সঠিক উত্তর পায়।
অটো-হিলিং, ইনক্রিমেন্টাল ব্যাকআপ, স্বাক্ষরিত আপডেট — এর কোনওটাই আপনাকে কনফিগার করতে হয় না। প্যানেলটাই এভাবে তৈরি।
কেন সহজ লাগে
সহজ একটা ডিজাইন-সিদ্ধান্ত, ওপরের রঙের প্রলেপ নয়
এর কোনোটাই আসল কন্ট্রোল লুকিয়ে রাখা কোনো সরলীকৃত মোড নয়। এগুলো আসল কন্ট্রোলই — এমনভাবে সাজানো, যাতে পরের ধাপটা সবসময় স্পষ্ট থাকে।
একবার পেস্ট, কোনো পূর্বশর্ত নেই
Docker শেখার দরকার নেই, compose ফাইল নেই, SSH-এর মুখে-মুখে চলা টোটকাও নেই। স্ট্যাকটা Ubuntu-র নিজস্ব প্যাকেজ, systemd-এর তত্ত্বাবধানে — আর একটি কমান্ডই পুরোটা বসিয়ে দেয়।
যে উইজার্ড নিজের উত্তর নিজেই বাতলে দেয়
ছয়টি ধাপ — বেসিকস, পাসওয়ার্ড, ডোমেইন, HTTPS, অ্যাপ্লিকেশন, ব্যাকআপ। প্রতিটি ধাপ যুক্তিসঙ্গত উত্তরটি নিজেই প্রস্তাব করে; সেটআপের বেশিরভাগটাই সিদ্ধান্ত নেওয়া নয়, নিশ্চিত করা।
একটি ডোমেইন লিখুন, পুরো পরিকল্পনা পান
একটিমাত্র ডোমেইন থেকে প্যানেল ছকে ফেলে ড্যাশবোর্ড, স্টোরফ্রন্ট আর ওয়েবসকেট হোস্ট, কোন DNS রেকর্ডগুলো বানাতে হবে, আর তার কোনগুলো Cloudflare প্রক্সি করবে। যে নাম চুপিসারে HTTPS ভেঙে দিত, তা বাতিল হয় — সঙ্গে যে বানানটা কাজ করবে সেটাও জানিয়ে।
সমস্যা আসে সমাধান সঙ্গে নিয়ে
খালি "failed" নয়। একটি লাল রো আপনাকে বলে দেয় ঠিক কোন সেটিং, ফাইল বা বাটনে সেটা মিটবে — একটি করণীয় আর একটি রহস্যের মধ্যে তফাতটা এখানেই।
প্রতিটি কাজই চোখের সামনে চলা জব
ইনস্টল, ডিপ্লয়, ব্যাকআপ আর ফিক্স — সবই চলে লাইভ লগসহ জব হিসেবে। কাজ চলাকালীন বাটনে স্পিনার ঘোরে, আর নিজের রি-চেক পাস না হওয়া পর্যন্ত কোনো জব সাকসেস বলতে রাজি হয় না।
ম্যানুয়াল থাকে প্যানেলের ভেতরেই
প্রতিটি Help লিংক নিয়ে যায় ঠিক সেই জিনিসটির পাতায়, যেটা আপনি তখন দেখছেন। একই ম্যানুয়াল ডাউনলোডের সঙ্গেও যায়, আর এই সাইটেও প্রকাশিত।
খারাপ দিনের জন্য একটি কমান্ড লাইন
সার্ভারে একটি sixpanel কমান্ড প্যানেলেরই প্রতিরূপ — man পেজ আর শেল কমপ্লিশনসহ — সেই দিনটির জন্য, যেদিন ব্রাউজার খোলার উপায় থাকবে না।
আপনার ভাষাতেই কথা বলে
আটটি ভাষা। এই সাইট থেকে গেলে প্যানেল খোলে সেই ভাষাতেই, যেটাতে আপনি পড়ছিলেন; আবার লিংক ধরে ফিরে এলে সাইটও তা-ই করে।
তিনটি জিনিস, যা আর কেউ করে না
তিনটি দাবি, প্রতিটি একটি বিশেষণের চেয়ে এটি সত্য হওয়ার কারণ সহ
আমরা একটি সম্পূর্ণ সুর করা প্রতিদ্বন্দ্বীর বিপরীতে নিজেদের বেঞ্চমার্ক করেছি, এবং জয় কোথা থেকে আসে তা প্রকাশ করেছি
যে-কেউ নিজে জেতা একটি বেঞ্চমার্ক প্রকাশ করতে পারে। চালানোর যোগ্য পরীক্ষা সেটিই, যেখানে অপর পক্ষকে ঠিকভাবে সাজানো হয় — তাই aaPanel মেশিনটিকে আগে টিউন করা হয়েছিল: কম্পাইল করা কোডের ক্যাশ দ্বিগুণ, ডেটাবেসের বাফার পুল সাড়ে চার গুণ বড়, ওয়ার্কার অতিরিক্ত-প্রতিশ্রুত 50 থেকে মাপমতো 14-তে সংশোধিত। এর PHP 8.4 আর এর JIT কম্পাইলার ইচ্ছাকৃতভাবেই চালু রাখা হয়েছে, কারণ ওগুলো এর সুবিধা।
ফাঁক বন্ধ হয়নি। 1.65× / 1.80× যেভাবে জাহির হয় তার বিপরীতে; 1.76× / 1.82× সুর করা একের বিপরীতে। এটি সামান্য অন্যদিকে চলেছে।
এরপর পার্থক্যটি একবারে একটি ভেরিয়েবল ধরে খুলে দেখা হয়েছে। এর প্রায় 60% একটিমাত্র PHP ডিরেক্টরি সীমাবদ্ধতা, প্রায় 8% ভুল JIT কম্পাইলার মোড, আর PHP সংস্করণের দাম ঠিক শূন্য। প্রায় 32% এখনো অব্যাখ্যাত, আর সেটি আমাদের কৃতিত্ব হিসেবে না দেখিয়ে অব্যাখ্যাত হিসেবেই প্রকাশ করা হয়েছে।
এটি কেন গণ্য: কোনো কারণ ছাড়া একটি অনুপাত একটি বিপণন সংখ্যা। এটির দুই-তৃতীয়াংশের জন্য পরিমাপ করা কারণ এবং বাকিটার জন্য একটি স্বীকৃতি রয়েছে।
আমরা তিনটি অপারেটিং সিস্টেম মেপেছি, ফল সমান হয়েছে, আর আমরা সেই সমান ফলই প্রকাশ করেছি
এক প্রোভাইডারের তিনটি সার্ভার, একসাথে অর্ডার করা, অপারেটিং সিস্টেম ছাড়া অভিন্ন। একই সফটওয়্যার, একই টিউনিং, একই ডেটা — 66,701 অর্ডারের একটি আসল দোকানের ডেটাবেস। এই রাউন্ডের প্রশ্ন কোন অপারেটিং সিস্টেম, কোন রানটাইম নয়; এটি কনটেইনারটিতে চালানো হয়েছিল।
ফল সমান হয়েছে। তিনটি মেশিনের মধ্যে ব্যবধান (3.5 %) একটি মেশিনের নিজের কনফিগারেশনে দুটি রানের মধ্যে নিজের সাথে নিজের ব্যবধানের (8.6 %) চেয়েও কম ছিল।
তাই সুপারিশ ঠিক হয়েছে গতি দেখে নয়, কোন সিস্টেম কত দিন নিরাপত্তা আপডেট পেতে থাকে তা দেখে। আর রিপোর্ট তার নিজের সবচেয়ে চাটুকার সারিগুলো বাদ দিয়ে দিয়েছে, কারণ সেগুলো হিসাবের দিক থেকেই অসম্ভব ছিল।
এটি কেন গণ্য: নেতিবাচক ফল প্রকাশ করার ইচ্ছাই প্রমাণ করে যে পদ্ধতিটি আসল। নিজে যে বেঞ্চমার্কে জিতেছে সেটি যে কেউ প্রকাশ করতে পারে।
6amMart-এর নিজের রিকোয়েস্ট প্যাটার্ন অনুযায়ী গড়া ক্যাশিং ও সীমা
nginx মাইক্রো-ক্যাশিং যে কারও হাতেই আছে। এখানে বিশেষ যা, তা হলো তার চারপাশের সবকিছু, আর এর কোনোটিই এমন কেউ লিখতে পারবেন না যিনি এই অ্যাপ্লিকেশনটি জানেন না:
- ঠিক কোন কোন পাবলিক এন্ডপয়েন্ট ক্যাশ হতে পারে তার একটি অনুমোদিত তালিকা, কাঁচা URI-তে মেলানো, ডিফল্ট-ডিনাই।
- ক্যাশ কি-তে জোন, মডিউল ও ভাষা, কারণ 6amMart একই URL থেকে ভিন্ন শহরে ভিন্ন স্টোর দেখায়।
- পাঁচটি বাইপাস নিয়ম, যা ব্যক্তিগত কোনো রেসপন্স ক্যাশ হওয়া অসম্ভব করে তোলে।
- রিকোয়েস্ট-হারের স্তর, যা লগইন ও OTP-কে ব্রাউজিং থেকে, সার্চ থেকে, আর কার্ট লেখা থেকে আলাদা করে।
- ইচ্ছে করে একে অন্যের সাথে মিলিয়ে বসানো টাইমআউট — PHP 120 s, nginx read 120 s, worker terminate 130 s — কারণ 6amMart Excel এক্সপোর্ট, বাল্ক ইমপোর্ট ও ভারী স্টোর রিপোর্ট ব্যাকগ্রাউন্ডে নয়, ওয়েব রিকোয়েস্টের ভেতরেই চালায়।
এটি কেন গণ্য: লগইন ছাড়াই একটি সার্চ ফ্লাড আগে ক্যাশ সার্ভার ভরে ফেলে সেশন সরাতে শুরু করতে পারত, ফলে সাইন-ইন করা ক্রেতারা চুপচাপ সাইন আউট হয়ে যেতেন। দুই-প্রকল্পের একটি 8 GB টেস্ট মেশিনে তাতে লাগত প্রায় 278টি রিকোয়েস্ট, একটি সংযোগে মোটামুটি 67 সেকেন্ড। সেটি মাপা হয়েছে, সীমা বাঁধা হয়েছে, আর একই মেশিনে আবার মাপা হয়েছে — প্রমাণ ফাইলে যে তিনটি ফ্লাডের ছক আছে, তার সবগুলোতেই শূন্য এভিকশন, আর প্রতিবারই সেশন টিকে ছিল।
SixPanel-এর তুলনা
aaPanel, CloudPanel আর হাতে করার সাথে SixPanel-এর তুলনা
এটি একটিমাত্র কাজের তুলনা: একটি 6amMart দোকান চালানো। এটি এই প্যানেলগুলোর সাধারণ তুলনা নয়, আর সেভাবে দেখানো অসৎ হতো।
দুই প্রতিযোগী সম্পর্কে আমাদের কাছে ঠিক কী আছে, নিখুঁতভাবে বলা
টেবিলটিতে ১৪টি সারি ও দুজন প্রতিযোগীর কলাম আছে, তাই ২৮টি প্রতিযোগী সেল। সেই ২৮টির মধ্যে চারটি "আমরা এটা পরীক্ষা করিনি" এর চেয়ে অন্য কিছু বলে, আর এখানে প্রতিটি একটি:
- একটি ঘরে এমন কিছু আছে যা আমরা একজন প্রতিযোগীর প্রোডাক্টকে করতে দেখেছি। সাইটের কোনো সেটিং সেভ করলেই aaPanel চুপচাপ ডকুমেন্ট রুট আগের অবস্থায় ফিরিয়ে দেয় — একটি লাইভ ইনস্টলে লিপিবদ্ধ। সেটি ডকুমেন্ট রুট সারির aaPanel কলাম।
- দুটি সেল নির্ভর করে একটি তৃতীয় পক্ষের আচরণের ওপর, যা আমরা যাচাই করেছি — প্যানেল পরীক্ষার ওপর নয়। Ubuntu 26.04-এর আর Debian 13-এর, কোনো আর্কাইভেই MariaDB 10.11 নেই, আর দুই প্যানেলই ডেটাবেস বসায় হোস্টের প্যাকেজ থেকে — তাই ওই রিলিজগুলোতে তারা সেই সংস্করণ দিতে পারে না। SixPanel-এর নেটিভ রানটাইম বদলে একই আর্কাইভ থেকে 11.8 নেয়, আর SixPanel Docker তার ইমেজে 10.11 বহন করে। এটিই MariaDB 10.11 সারি, দুটি প্রতিযোগী কলামেই।
- একটি ঘরে আছে একজন প্রতিযোগীর নিজেদের হাতে করা আমাদের মাপ। aaPanel অভিন্ন হার্ডওয়্যারে একই দোকানের ডেটা নিয়ে বসানো হয়েছিল, আগে আমরাই সেটি টিউন করেছি, তারপর মেপেছি — সেটি গতির সারির aaPanel কলাম, আর পুরো পদ্ধতিটি উপরে আছে। CloudPanel মাপা হয়নি, তাই তার ঘরে সেটিই লেখা।
- বাকি ২৪টি প্রতিযোগী সেল সবই বলে "আমাদের দ্বারা পরীক্ষিত নয়"। এটি প্রতিটিতে আক্ষরিক শব্দটি — ধরে নয়, গণনা করা।
কোনো প্রতিযোগী কত পুরোনো, সে বিষয়ে আমরা কোনো দাবি করি না। এই তথ্যের কোনো উৎসেই কোনো প্রোডাক্টের বয়স প্রতিষ্ঠিত হয় না, তাই এমন কোনো দাবিও নেই। ট্র্যাক রেকর্ড সারিতে সৎভাবে কেবল আমাদের নিজেদের বয়সের কথাই বলা যায়।
আমরা এখন SixPanel কে aaPanel-এর বিপরীতে বেঞ্চমার্ক করেছি — অভিন্ন হার্ডওয়্যার, একই দোকানের ডেটা, এবং aaPanel সংখ্যা নেওয়ার আগে সুর করা। পদ্ধতি ও প্রতিটি চিত্র উপরে। CloudPanel একেবারে পরিমাপ করা হয়নি, আর এই পৃষ্ঠায় এর বিষয়ে কোনো গতির দাবি কোথাও আসে না।
| 6amMart চালানোর কাজের জন্য | SixPanel | aaPanel | CloudPanel | সাধারণ সার্ভার, হাতে |
|---|---|---|---|---|
| এটি কীসের জন্য তৈরি | কেবল একটি অ্যাপ্লিকেশন — 6amMart | সাধারণ ওয়েব হোস্টিং — আমরা পরীক্ষা করিনি; ভেন্ডরের নিজের ফিচার তালিকা দেখুন | সাধারণ ওয়েব হোস্টিং — আমরা পরীক্ষা করিনি; ভেন্ডরের নিজের ফিচার তালিকা দেখুন | আপনি যা বানাবেন |
| গতি, একই হার্ডওয়্যার ও একই দোকান | মেপে দেখা: পূর্ণভাবে টিউন করা aaPanel-এর চেয়ে এক অনুরোধে 1.76× দ্রুত, একসাথে চারটিতে 1.82×, দুই দিকেই PHP পর্যন্ত পৌঁছানো এন্ডপয়েন্টগুলোতে | উপরের তুলনা। আমরা এটি ইনস্টল করেছি, সুর করেছি, এবং এর PHP 8.4 ও JIT জায়গায় রেখেছি | আমাদের দ্বারা পরীক্ষিত নয় — গতি সম্পর্কে কোনো দাবি করা হয় না | যাই হোক না কেন আপনার প্রকৌশলী অর্জন করেন |
| Ubuntu 26.04 / Debian 13-এ MariaDB 10.11 | Docker রানটাইমে, হ্যাঁ — হোস্টে যা-ই চলুক, ইমেজটি 10.11-এ আটকানো। নেটিভ রানটাইম বদলে ওই রিলিজগুলোর নিজের আর্কাইভ থেকে MariaDB 11.8 নেয়, আর একই দোকানে 10.11-এর বিপরীতে মেপে দেখা গেছে সেটি সমানে-সমান। | পাওয়া যায় না। কোনো রিলিজের আর্কাইভেই 10.11 নেই, আর এই প্যানেল হোস্টের প্যাকেজ থেকে ইনস্টল করে | পাওয়া যায় না — একই কারণে | কেবল যদি আপনি নিজেই কনটেইনার চালান |
| একই মেশিনে অন্য ওয়েবসাইট, মেইল, DNS, FTP | না। যে সার্ভারে আগে থেকেই aaPanel, CloudPanel, cPanel বা Plesk চলছে, কিংবা 80/443 পোর্টে কিছু আছে, ইনস্টলার সেটি ফিরিয়ে দেয় | এখানে তারা জেতে। সাধারণ প্যানেল এ জন্যই — আমরা পরীক্ষা করিনি; ভেন্ডরকে দেখুন | এখানে তারা জেতে — আমরা পরীক্ষা করিনি; ভেন্ডরকে দেখুন | সম্ভব, আর পুরোপুরি আপনার দায় |
| ব্যবহারকারী, রোল, টিম | না। একটি অ্যাডমিন অ্যাকাউন্ট। সাথে অস্থায়ী লগইন আর একটি রিড-অনলি ডেমো লগইন | এখানে তারা জেতে। আমরা পরীক্ষা করিনি; ভেন্ডরকে দেখুন | এখানে তারা জেতে। আমরা পরীক্ষা করিনি; ভেন্ডরকে দেখুন | আপনি যা কনফিগার করবেন |
| শুরু থেকেই এই অ্যাপ্লিকেশনের জন্য টিউন করা | Autotune আসল মেশিন দেখে PHP ওয়ার্কার, ডেটাবেসের বাফার পুল, ক্যাশের মেমরি, টেম্পোরারি টেবিল, বাফার ও রিডু লগ লিখে দেয়, 1 কোর / 2 GB → 16 কোর / 32 GB — আর যে দুই জায়গায় এটি হিসাব হয়, প্রতিটি বিল্ডে দুটিকে মিলিয়ে দেখা হয় | nginx মাইক্রো-ক্যাশিং সবখানেই পাওয়া যায় — 6amMart-নির্দিষ্ট নিয়মগুলো কাউকে লিখতে হয়। আমরা পরীক্ষা করিনি | একই। আমরা পরীক্ষা করিনি | আপনি যতটা জানেন |
| 6amMart-এর মতো করে গড়া মাইক্রো-ক্যাশ | ভেতরেই আছে: অনুমোদিত তালিকা, কি-তে জোন/মডিউল/ভাষা, 5টি বাইপাস, PHP আটকে গেলে পুরোনো কপি পরিবেশন | nginx মাইক্রো-ক্যাশিং সবখানেই পাওয়া যায় — 6amMart-নির্দিষ্ট নিয়মগুলো কাউকে লিখতে হয়। আমরা পরীক্ষা করিনি | একই। আমরা পরীক্ষা করিনি | একই |
| ব্যাকআপ | restic, নির্ধারিত সময়ে, রিটেনশন, চারটি গন্তব্য, সাপ্তাহিক স্বয়ংক্রিয় রিস্টোর টেস্ট | আমরা পরীক্ষা করিনি — বিশেষ করে স্বয়ংক্রিয় রিস্টোর টেস্টটি মিলিয়ে দেখুন | আমরা পরীক্ষা করিনি — একই | আপনি যা স্ক্রিপ্ট করবেন |
| ফ্রি HTTPS | হ্যাঁ, স্বয়ংক্রিয় নবায়ন ও Cloudflare-সচেতন ইস্যুসহ | আমরা পরীক্ষা করিনি; ভেন্ডরকে দেখুন | আমরা পরীক্ষা করিনি; ভেন্ডরকে দেখুন | certbot, আপনার হাতে |
| ডিপ্লয় | git-এ push; শেষ 30টি ডিপ্লয়সহ ইতিহাস ও রোলব্যাক; আপনার সম্পাদনা মুছে দিতে অস্বীকার করে | একটি লাইভ ইনস্টলে লিপিবদ্ধ: সাইটের কোনো সেটিং সেভ করলেই aaPanel চুপচাপ ডকুমেন্ট রুট আগের অবস্থায় ফিরিয়ে দেয় | আমরা পরীক্ষা করিনি | আপনি যা স্ক্রিপ্ট করবেন |
| ডকুমেন্ট রুট যেখানে রেখেছেন সেখানেই থাকে | হ্যাঁ | একটি লাইভ ইনস্টলে লিপিবদ্ধ: সাইটের কোনো সেটিং সেভ করলেই aaPanel চুপচাপ ডকুমেন্ট রুট আগের অবস্থায় ফিরিয়ে দেয় | আমরা পরীক্ষা করিনি | ঠিক রাখা আপনার দায় |
| ট্র্যাক রেকর্ড | SixPanel তার চলতি রিলিজে আছে, আর এটি নতুন। যে বছরগুলো আমাদের হয়নি, সেগুলো আমরা দেখাতে পারি না | আমরা পরীক্ষা করিনি; ভেন্ডর কত দিন ধরে শিপ করছে দেখুন | আমরা পরীক্ষা করিনি; ভেন্ডর কত দিন ধরে শিপ করছে দেখুন | Linux 30+ বছরের পুরোনো |
| আপনার সার্ভারে পড়ার মতো সোর্স কোড | এখানে তারা জিততে পারে। প্যানেলের ব্যাকএন্ড V8 বাইটকোড হিসেবে যায় আর পড়ার মতো সোর্স সরিয়ে দেওয়া হয়। আমরা একে নিরাপত্তা নয়, প্রতিবন্ধক বলি | আমরা পরীক্ষা করিনি; ভেন্ডর কী সাপোর্ট দেয় দেখুন | আমরা পরীক্ষা করিনি; ভেন্ডর কী সাপোর্ট দেয় দেখুন | সবকিছুই পড়া যায় |
| ভাঙলে কে ঠিক করে | হেলথ পেজ ফিক্সটির নাম বলে; এক কমান্ডে সাপোর্ট বান্ডল | আমরা পরীক্ষা করিনি; ভেন্ডর কী সাপোর্ট দেয় দেখুন | আমরা পরীক্ষা করিনি; ভেন্ডর কী সাপোর্ট দেয় দেখুন | আপনি |
দামের কোনো সারি নেই, কারণ কোনো দামই নেই। SixPanel ফ্রি, CodeCanyon-এ প্রকাশিত, আর ইনস্টল কমান্ডটি সবার জন্য একই পাবলিক কমান্ড — কোনো কী বসাতে হয় না, কোনো কোড পেস্ট করতে হয় না, কোথাও সাইন আপ করতে হয় না। প্রথম ইনস্টলেশন ও সেটআপও ফ্রি। আপডেট আসে CodeCanyon-এর মাধ্যমে, আর প্যানেল নিজেও নিজেকে আপডেট করতে পারে।
কখন aaPanel বা CloudPanel-ই ভালো পছন্দ
পাঁচটি বাস্তব ক্ষেত্র। এর কোনোটি যদি আপনি হন, তাহলে সাধারণ প্যানেলটাই কিনুন, এটি কিনবেন না:
- 1আপনি ওই সার্ভারে একাধিক ওয়েবসাইট চান। SixPanel পুরো মেশিনটাই নেয় আর ভাগ করতে অস্বীকার করে।
- 2একই মেশিনে আপনার মেইল, DNS বা FTP হোস্টিং দরকার। SixPanel এগুলো একেবারেই করে না।
- 3আপনার আলাদা আলাদা পারমিশনসহ কয়েকটি কর্মী অ্যাকাউন্ট দরকার। SixPanel-এ একটিই অ্যাডমিন অ্যাকাউন্ট, কোনো রোল নেই।
- 4আপনি 6amMart ছাড়া অন্য কিছু চালাচ্ছেন। এই পেজের প্রতিটি সুবিধা আসে একটি অ্যাপ্লিকেশন ভালোভাবে জানা থেকে।
- 5দীর্ঘ প্রোডাকশন ট্র্যাক রেকর্ড আপনার প্রথম শর্ত। SixPanel নতুন। অপেক্ষা করার এটি যুক্তিসঙ্গত কারণ।
আর হাতে করার পক্ষে একটি কথা: আপনার যদি একজন সিসঅ্যাডমিন থাকেন, তাহলে হাতে বানানো সার্ভার খারাপ কিছু নয়। একজন দক্ষ ইঞ্জিনিয়ার MariaDB টিউন করতে, ক্যাশ নিয়ম লিখতে আর ব্যাকআপ স্ক্রিপ্ট করতে পারেন। SixPanel যা সরিয়ে দেয় তা হলো সেই মানুষটির দরকার, আর এর কোনোটি আবার মিলিয়ে দেখার কথা মনে রাখার দরকার।
অপারেটিং সিস্টেম
অপারেটিং সিস্টেম
দুটি রানটাইমই Ubuntu 26.04 LTS সুপারিশ করে। Ubuntu 24.04 LTS ও Debian 13 হলো বাকি দুটি সমর্থিত রিলিজ।
এটি দ্রুততর, সে কারণে নয়। অভিন্ন হার্ডওয়্যারে ছয়টি অক্ষ মাপা হয়েছে — অপারেটিং সিস্টেম, PHP, MariaDB, nginx, Redis আর কার্নেল — আর কোনো সংস্করণ বদলে রিপোর্ট করার মতো পার্থক্য আসেনি। বাইট-হিসেবে অভিন্ন দুটি মেশিন 20-এর মধ্যে 20টি সারিতে নিজেদের মধ্যেই 11.6 % অমিল দেখিয়েছে, অর্থাৎ পাওয়া যে-কোনো প্রভাবের চেয়ে নয়েজের মেঝেটাই বড়।
নেটিভ রানটাইম PHP, MariaDB, nginx ও Redis নেয় রিলিজের নিজের ডিস্ট্রিবিউশন আর্কাইভ থেকে, আর তিনটি সমর্থিত রিলিজেই একটি কার্যকর সেট আছে: Ubuntu 26.04 দেয় PHP 8.5 ও MariaDB 11.8, Debian 13 দেয় 8.4 ও 11.8, Ubuntu 24.04 দেয় 8.3 ও 10.11। গতি যখন সমানে-সমান, বাকি থাকে কেবল একটি অক্ষ — নিরাপত্তা আপডেট আর কত দিন আসতে থাকবে — আর 26.04-এ প্যাচ আসবে এপ্রিল 2031 পর্যন্ত।
SixPreflight Ubuntu 26.04 LTS সুপারিশ করে, নেটিভ রানটাইম যে কারণে করে ঠিক সেই কারণেই।
| পছন্দ | SixPanel / SixPanel Docker | SixPreflight |
|---|---|---|
| সুপারিশকৃত | Ubuntu 26.04 LTS, দুটি রানটাইমেই | Ubuntu 26.04 LTS |
| এগুলোও সমর্থিত | দুটি রানটাইমেই: Ubuntu 24.04 LTS ও Debian 13। Docker রানটাইম Debian 12-তেও বসে, যেটি নেটিভ রানটাইম নাম ধরে বাতিল করে | Ubuntu 24.04 LTS, Debian 13 |
| কেন | তিনটিতেই গতি সমানে-সমান, তাই সিদ্ধান্তটি নির্ভর করে সাপোর্টের বাকি মেয়াদের উপর: 26.04-এ প্যাচ আসবে এপ্রিল 2031 পর্যন্ত। নেটিভ রানটাইম আপনি যে রিলিজ বেছে নেবেন, তার থেকেই PHP ও MariaDB নেয়। | একই কারণে: ডেটাবেস আসে অপারেটিং সিস্টেম থেকে, প্রতিটি সমর্থিত রিলিজেই একটি কার্যকর সংস্করণ আছে, তাই বেছে নেওয়ার মতো বাকি থাকে কেবল সাপোর্টের মেয়াদ। |
সমর্থিত হওয়া আর মাপা হওয়া এক নয়। নেটিভ রানটাইম তিনটি রিলিজ সমর্থন করে, আর তিনটিই মাপা হয়েছে — Ubuntu 24.04, Ubuntu 26.04 ও Debian 13। Debian 12 নাম ধরে বাতিল করা হয়: এর ফ্রি নিরাপত্তা সাপোর্ট জুলাই 2026-এ শেষ হয়েছে। Docker রানটাইম এখনো এতে বসে, তবুও নতুন দোকান এখানে শুরু করা উচিত নয় — কারণ কনটেইনারের ভিতরে যা-ই চলুক, কার্নেল, glibc, Docker আর OpenSSH আসে হোস্টের আর্কাইভ থেকেই।
একই fact কেন তিন different উপায় point করে
আগের একটি ডেটাবেস-ইঞ্জিন রাউন্ড MariaDB 10.11-কে প্রথমে রেখেছিল, আর কিছুদিন সেটিই সুপারিশটাকে দুভাগ করে রেখেছিল, কারণ কেবল Ubuntu 24.04-এই সেটি ছিল। একই 66,701 অর্ডারের দোকান নিয়ে অভিন্ন মেশিনে আবার মেপে দেখা গেছে, সেই ভাগ আর নেই।
পুরো অ্যাপ্লিকেশনে 10.11-এর বিপরীতে MariaDB 11.8 সমানে-সমান। যে সারিগুলো উল্টোটা ইঙ্গিত করেছিল সেগুলো বাদ দেওয়া হয়েছে, কারণ হার্নেসটি ডেটাবেস নয়, একটি এনক্রিপ্টেড হ্যান্ডশেকের সময় মাপছিল।
যে একটিমাত্র জায়গায় 11.8 ধীর দেখাচ্ছিল, সেটি কোনো কাজই করে না।
সেটি ছিল SELECT 1 — এমন একটি স্টেটমেন্ট যা কোনো কাজ করে না, এক বাহুতে পড়েছে 12 ms আর বাকি দুটিতে 29 ms ও 37 ms। যে মেঝে তিন গুণ পর্যন্ত সরে যায় সেটি কোয়েরি এক্সিকিউশন নয়: MariaDB 11.8 unix socket-এ TLS নেগোশিয়েট করে আর 10.11 করে না, তাই প্রোবটি আসলে একটি হ্যান্ডশেকের সময় মাপছিল। সরাসরি মেপে: 11.8-এ প্রতি ক্লায়েন্ট কলে 24 ms, TLS বন্ধ রেখে 6 ms, আর 10.11-এ 10 ms। দোকান এটি কখনোই দেয় না — mysqlnd socket-এ TLS নেগোশিয়েট করে না, প্রতি কানেক্টে 0.12 থেকে 0.21 ms।
পুরোনো “11.x 2.7× ধীর” হিসাবটি কখনোই 11.8 নিয়ে ছিল না।
এটি এসেছিল MariaDB 11.0-এর কস্ট মডেলে চালানো একটিমাত্র রিপোর্ট কোয়েরি থেকে, আর পুরো-অ্যাপ্লিকেশনের দাবি হিসেবে সেটি প্রত্যাহার করা হয়েছে। তাই পুরোনো রিলিজে আটকে থাকার পক্ষে এখন আর কিছুই বলে না: নেটিভ রানটাইম Ubuntu 26.04-এর ও Debian 13-এর নিজের আর্কাইভ থেকে 11.8 নেয়, আর Ubuntu 24.04-এর থেকে 10.11।
একই fact, ভিন্ন উত্তর — কারণ উত্তর depend করে কোথায় database আসে।
কীভাবে মাপা হয়েছে
- মাপা হয়েছে 15 আগস্ট 2026-এ, সেদিনের চলতি স্ট্যাক বিল্ডে। এরপর SixPanel-এর নতুন রিলিজ এসেছে, আর এই অংশের কিছুই চলতি রিলিজে আবার চালানো হয়নি। তারিখটিই মাপটিকে বেঁধে রাখে।
- একই প্রোভাইডারের তিনটি সার্ভার, একসাথে অর্ডার করা, অপারেটিং সিস্টেম ছাড়া সবই অভিন্ন — আর সেই তিনটিই নেটিভ রানটাইমের সমর্থিত প্রতিটি রিলিজ।
- তিনটিতেই একই প্রসেসর: 2 × AMD EPYC 7713, 2টি কোর। RAM 3,915 / 3,910 / 3,921 MB। ডিস্ক প্রতিটিতে 79 GB।
- সফটওয়্যার সব তিনটি জুড়ে byte-identical ছিল — MariaDB 10.11, একই PHP build flags সঙ্গে, একই Redis version, একই nginx version, একই হার্ডওয়্যার। একটি git hash verify করেছে কোডের।
- আসল ডেটা, বানানো নমুনা নয়। একটি আসল প্রোডাকশন দোকানের ডেটাবেস: 410 MB-র একটি ডাম্প যা 515 MB-তে রিস্টোর হয়, 66,701টি অর্ডার, সাথে 894 MB আসল আপলোড।
- প্রতিটি মেশিনে নতুন করে SixPanel ইনস্টল, স্বাভাবিক গ্রাহক-পথ ধরে। কোনো হাতে টিউনিং নয় — প্রতিটি মান autotune বেছেছে, আর তিনটিতেই একই মান বেছেছে।
- আগে গরম করা, তারপর মাপা। ওয়ার্ম-আপের নমুনা বাদ; দ্বিতীয় রানটিই রিপোর্ট করা হয়েছে।
- গড় নয়, পার্সেন্টাইল।
প্রতি সেকেন্ডে রিকোয়েস্ট — সার্চ এন্ডপয়েন্ট, একসাথে 20 জন, 30 সেকেন্ড
এই সংখ্যাটিকেই বিশ্বাস করুন।
| অপারেটিং সিস্টেম | সম্পন্ন রিকোয়েস্ট | প্রতি সেকেন্ডে রিকোয়েস্ট |
|---|---|---|
| Ubuntu 24.04 | 1,561 | 52.0 |
| Ubuntu 26.04 | 1,616 | 53.9 |
| Debian 13 | 1,595 | 53.2 |
তিনটির মধ্যে ব্যবধান: 3.5 %। Ubuntu 26.04 মেশিনটি নিজের অভিন্ন কনফিগারেশনে দুটি রানে নিজের সাথেই 8.6 % অমিল দেখিয়েছে — 49.6, তারপর 53.9।
হিসাবের নোট, কারণ যে পেজ অসম্ভব সংখ্যা ধরাকে গুণ হিসেবে দেখায়, সেই পেজ এমন শতাংশ ছাপতে পারে না যা পাশের সংখ্যাগুলো থেকে পাঠক বের করতে পারবেন না। ভেতরের রিপোর্টে ব্যবধান ছাপা আছে 3.7 % আর নিজের-সাথে-নিজের পার্থক্য 8.7 %। দুটিই উপরের দিকে রাউন্ড করা, তাই এই পেজ তার বদলে কেটে ফেলা হিসাব ছাপে: (1,616 − 1,561) ÷ 1,561 = 3.5234 % → 3.5 %, আর (53.9 − 49.6) ÷ 49.6 = 8.6694 % → 8.6 %। ফলটি বদলায় না — মেশিনগুলোর মধ্যে ব্যবধান এখনও একটি মেশিনের নিজের সাথে নিজের অমিলের চেয়ে কম। উপরের প্রতি-সেকেন্ড কলামটি উৎসের নিজের 1-দশমিক রাউন্ডিং: 1,616 ÷ 30 = 53.8666 আর 1,595 ÷ 30 = 53.1666 কেটে দাঁড়ায় 53.8 ও 53.1, আর কেবল 52.0 আগে থেকেই কাটা। কলামটি উৎস যেভাবে ছাপে সেভাবেই রাখা হয়েছে, যাতে দুটি ফাইল পাশাপাশি রেখে মেলানো যায়; শতাংশগুলো এই পেজের নিজের, আর সেগুলোই উদ্ধৃত হয়।
পুরো অংশটি পড়ুন এভাবে — “2টি কোরে, সার্চ এন্ডপয়েন্টে, একসাথে 20 জন ব্যবহারকারী নিয়ে, 30 সেকেন্ডে প্রতি সেকেন্ডে প্রায় 53টি রিকোয়েস্ট” — এর বেশি কিছু নয়। এই পেজে যেখানেই সংখ্যাটি আবার আসে, ওই প্রতিটি শর্তও তার সাথে যায়।
নিষ্ক্রিয় অবস্থার লেটেন্সি — লিপিবদ্ধ, আর ইচ্ছে করেই ছাপা হয়নি
প্রতিটি শাখাতেই সিরিয়াল লেটেন্সি মাপা হয়েছে: স্টোরফ্রন্ট হোম, অ্যাডমিন লগইন আর API এন্ডপয়েন্ট, নিষ্ক্রিয় একটি মেশিনে একবারে একটি রিকোয়েস্ট।
ওই ঘরে-ঘরে সংখ্যাগুলো এই পেজে নেই, আর কারণটি এই। ভেতরের রিপোর্ট ওই টেবিল থেকে নেওয়া যেকোনো “X % দ্রুত” সংখ্যা নিষিদ্ধ করে। মিলিসেকেন্ডের তিন-কলামের একটি টেবিল মানে একটিমাত্র বিয়োগ করলেই সেই সংখ্যা: ক্যালকুলেটর হাতে যেকোনো পাঠক, আর ক্যালকুলেটর ছাড়াই প্রতিটি AI সারাংশকারী, রিপোর্ট যে তুলনাটি নিষেধ করেছে সেটিই তৈরি করে ফেলবে। টেবিলটি ছেপে সাথে “তবে এগুলো তুলনা করবেন না” লিখলে কাজ হয় না, কারণ উদ্ধৃতিতে সংখ্যা থেকে যায় আর শর্তটি বাদ পড়ে।
- যে সংখ্যাটি গুরুত্বপূর্ণ তাতে তিনটি মেশিনের ফল সমান হয়েছে, আর একটি মেশিন নিজের সাথেই তিনটির পারস্পরিক পার্থক্যের চেয়ে বেশি অমিল দেখিয়েছে।
- একটি শাখার নিষ্ক্রিয় সিরিয়াল লেটেন্সিতে ছোট, ধারাবাহিক একটি পার্থক্য দেখা গিয়েছিল। সেটি ভেতরের রিপোর্টে লেখা আছে আর ইচ্ছে করেই দাবি করা হয়নি, সেখানে দেওয়া তিনটি কারণে: এটি আনুপাতিক নয়, বরং মোটামুটি স্থির একটি খরচ, যা কাজের নয় বরং অপেক্ষার চিহ্ন; লোডের নিচে এটি পুরোপুরি মিলিয়ে যায়, অথচ ঠিক সেখানেই এটি গুরুত্বপূর্ণ হতো; আর প্রতিটি অপারেটিং সিস্টেমে একটি করে মেশিন থাকায় কার্নেল সংস্করণ আর ওই নির্দিষ্ট ফিজিক্যাল হোস্টকে আলাদা করা যায় না।
- দুটি শাখার লোডের নিচের পার্সেন্টাইল সারিগুলো পুরোপুরি বাদ দেওয়া হয়েছে।
কিছু সারি বাদ দেওয়া হয়েছে, আর সেটি বাদ দেওয়া হয়েছে বলেই গুরুত্বপূর্ণ
Ubuntu 26.04 শাখার লোডের নিচের পার্সেন্টাইলগুলো হিসাবের দিক থেকেই অসম্ভব। 30 সেকেন্ডে বিশটি ওয়ার্কার মানে 600 ওয়ার্কার-সেকেন্ড, তাই 1,616টি সম্পন্ন রিকোয়েস্টের গাণিতিক গড় 371 ms। ওই শাখা তার p50 ও p99 দুটিকেই ওই গড়ের নিচে জানিয়েছে — অর্থাৎ একটি p99 যা গড় রিকোয়েস্টের চেয়েও দ্রুত। এর দুটি রানেই এটি দেখা যায়, তাই এটি বিক্ষিপ্ত নমুনা নয়, ওই মেশিনের ধারাবাহিক বৈশিষ্ট্য।
চোখ বুজে মেনে নিলে ওই সারিগুলো মেশিনটিকে লোডের নিচে অসাধারণ ভালো দেখাত। তা নয় — তার সম্পন্ন রিকোয়েস্টের সংখ্যা বাকিদের 3.5 %-এর মধ্যেই। ওই দুটি পার্সেন্টাইল মান এই পেজে ছাপা হয়নি: ভেতরের রিপোর্ট Ubuntu 26.04-এর লোডের নিচের লেটেন্সির সংখ্যাগুলোকে একটি শ্রেণি হিসেবেই বাদ দেয়। কেন সেগুলো বাদ গেল তা দেখানোর জন্য উপরের হিসাবই যথেষ্ট, আর বাদ দেওয়াটাই এখানে মূল কথা।
টেস্ট হারনেসে এখন Little's Law-ভিত্তিক একটি ক্রস-চেক আছে, যাতে নষ্ট নমুনা শিরোনাম হয়ে যাওয়ার বদলে নিজেই নিজের কথা জানিয়ে দেয়।
ডেটাবেস, আসল 515 MB ডেটাসেটে
সংখ্যাগুলোর আগে শর্তটি পড়ুন। এই টেবিলে মেশিনে-মেশিনে প্রতিটি পার্থক্যই একই তিনটি কোয়েরিতে Ubuntu 24.04-এর নিজের রান-থেকে-রান পরিসর 85–125 ms-এর ভেতরে পড়ে। কলামগুলো কোনো ক্রম-তালিকা নয়; এগুলো একটি সংখ্যার তিনটি নমুনা। আসল ফলটি শেষ সারিতে।
| কোয়েরি | Ubuntu 24.04 | Ubuntu 26.04 | Debian 13 |
|---|---|---|---|
| সব অর্ডার গণনা | 120 ms | 96 ms | 106 ms |
| সব অর্ডার লাইন গণনা | 102 ms | 102 ms | 110 ms |
| অর্ডারের সাথে অর্ডার লাইন জয়েন, 50টি সারি | 85 ms | 80 ms | 81 ms |
| বাফার-পুল হিট রেট | 99.991 % | 99.989 % | 99.987 % |
শেষ সারিটিই ফল: 1,024 MB বাফার পুলের ভেতরে 515 MB-র একটি ডেটাবেস মানে পড়ার প্রায় 99.99 % উত্তর মেমরি থেকেই আসে, আর একবার গরম হয়ে গেলে এই কাজ ডিস্ক পড়া বন্ধ করে দেয়।
ইনস্টলে কত সময় লেগেছে
| অপারেটিং সিস্টেম | নজরদারি ছাড়া ইনস্টল | সমস্যা |
|---|---|---|
| Ubuntu 24.04 | 303 s | নেই |
| Ubuntu 26.04 | 281 s | নেই |
| Debian 13 | 273 s | মিনিমাল ইমেজে git নেই, ফলে ক্লোন একেবারেই ভেঙে যায় — এখানেই ধরা পড়েছে, এখানেই ঠিক করা হয়েছে |
303 s মানে পাঁচ মিনিট তিন সেকেন্ড, আর এ কারণেই এই পেজ লেখে “প্রায় পাঁচ মিনিট”, “পাঁচ মিনিটের কম” নয়।
এপ্রিল 2031 কেন সিদ্ধান্ত ঠিক করে দিল
গতিতে ফল সমান হওয়ায় সিদ্ধান্তের উপাদান হলো কোন সিস্টেম কত দিন নিরাপত্তা আপডেট পেতে থাকে। অপারেটিং সিস্টেমের সাপোর্ট ফুরিয়ে যাওয়াই একমাত্র ঘটনা যা পুরো সার্ভার নতুন করে বানাতে বাধ্য করে — আর সার্ভার নতুন করে বানানোই একমাত্র কাজ যা SixPanel তার মালিকের হয়ে করতে পারে না।
| অপারেটিং সিস্টেম | ফ্রি নিরাপত্তা সাপোর্ট যত দিন | আগস্ট 2026 থেকে বাকি মেয়াদ |
|---|---|---|
| Ubuntu 26.04 LTS | এপ্রিল 2031 | 4 বছর 8 মাস |
| Ubuntu 24.04 LTS | এপ্রিল 2029 | 2 বছর 8 মাস |
| Debian 13 | মোটামুটি 2028-এর মাঝামাঝি, তারপর কমিউনিটি LTS | প্রায় 1 বছর 10 মাস |
| Debian 12 | জুলাই 2026-এ শেষ হয়েছে | শেষ |
MariaDB 10.11-এর নিজের মেয়াদ ফুরায় মোটামুটি ফেব্রুয়ারি 2028-এ। কনটেইনার রানটাইমে সেটি একটি ইমেজ পিন আর আলাদা একটি সিদ্ধান্ত; নেটিভ রানটাইমে এটি কেবল Ubuntu 24.04-এর ক্ষেত্রেই খাটে, কারণ 26.04 ও Debian 13 নিজেদের আর্কাইভ থেকে 11.8 নেয়। যেভাবেই হোক, এ কারণেই হোস্ট অপারেটিং সিস্টেম এমন হওয়া উচিত যেটি সবচেয়ে কম বার বদলাতে হয়।
আপনার হোস্টিং কোম্পানি এখনও Ubuntu 26.04 না দিলে Ubuntu 24.04 নিন। এটি পুরোপুরি সমর্থিত, আর মাপা যায় এমন কিছুই আপনি হারাবেন না।
নিরাপদে বলা যায়, আর এই পেজ সেগুলো বলে
- SixPanel Ubuntu 26.04, Ubuntu 24.04 ও Debian 13-এ — যে তিনটি মাপা হয়েছে — পুরো 6amMart স্ট্যাক চালায়, আসল প্রোডাকশন ডেটায় যাচাই করা।
- প্রতিটি সমর্থিত রিলিজের নিজের আর্কাইভেই একটি কার্যকর ডেটাবেস আছে — Ubuntu 26.04 ও Debian 13-এ MariaDB 11.8, Ubuntu 24.04-এ 10.11 — আর একই দোকানে মেপে দেখা গেছে, 10.11-এর বিপরীতে 11.8 সমানে-সমান। ঠিক ওই সংস্করণটিই চাইলে কনটেইনার রানটাইম তার ইমেজে 10.11 আটকে রাখে।
- Ubuntu 26.04 LTS প্রস্তাবিত, আর এটি এপ্রিল 2031 পর্যন্ত নিরাপত্তা আপডেট পায়।
- একটি 2-কোর / 4 GB সার্ভার সার্চ এন্ডপয়েন্টে একসাথে 20 জন ব্যবহারকারী নিয়ে 30 সেকেন্ডে প্রতি সেকেন্ডে প্রায় 53টি রিকোয়েস্ট পরিবেশন করেছে, 66,701টি অর্ডারের লাইভ-আকারের ক্যাটালগে, আর ডেটাবেস পড়ার 99.99 % উত্তর মেমরি থেকে দিয়েছে।
- নতুন একটি ইনস্টল নজরদারি ছাড়াই প্রায় পাঁচ মিনিটে শেষ হয় (মাপা 273–303 s; তিনটির মধ্যে সবচেয়ে ধীর 303 s-এর ভিত্তিতেই লেখাটি লেখা)।
মাপ এগুলো সমর্থন করে না, আর এই পেজ সেগুলো বলে না
- এই অপারেটিং সিস্টেমগুলোর কোনো একটি অন্যটির চেয়ে দ্রুত। মাপা পার্থক্যগুলো একটিমাত্র মেশিনের নিজের ওঠানামার চেয়েও কম।
- ভেতরের লেটেন্সি টেবিল থেকে বের করা শতাংশ-দ্রুততার কোনো সংখ্যা। মেশিনগুলোর মধ্যে ব্যবধান 3.5 %, আর নিজের-সাথে-নিজের অমিল 8.6 % — এ কারণেই ঘরে-ঘরে কোনো লেটেন্সি টেবিলই দেওয়া হয়নি।
- Ubuntu 26.04-এর লোডের নিচের লেটেন্সির সংখ্যাগুলো। সেগুলো হিসাবের দিক থেকেই অসম্ভব এবং বাদ দেওয়া হয়েছে।
- ডিস্কের গতি নিয়ে কিছু। ওই কলামটি দেখায় কোন সার্ভার কোন ফিজিক্যাল মেশিনে পড়েছে, অপারেটিং সিস্টেম নয় — আর তাতে কোনো দিকেই কিছু আসে-যায়নি, কারণ ডেটাবেস পড়ার 99.99 % উত্তর মেমরি থেকে দেয় এবং একবার গরম হলে ডিস্কে হাত দেওয়া বন্ধ করে।
- “6amMart এত দ্রুত” ধরনের কোনো সাধারণ সংখ্যা। প্রতি সেকেন্ডে 53টি রিকোয়েস্ট বলে একটি এন্ডপয়েন্টের কথা, এই ডেটায়, 2টি কোরে, একসাথে 20 জন ব্যবহারকারী নিয়ে 30 সেকেন্ডে।
- 8 GB বা তার বড় সার্ভার নিয়ে কিছু। এই রাউন্ডে কেবল 4 GB মেশিনই মাপা হয়েছে।
- Debian 12-এর গতি নিয়ে কিছু। এটি সমর্থিত, কিন্তু মাপা হয়নি।
এই রাউন্ড যা ভেঙেছে, আর আমরা যা ঠিক করেছি
তিনটি আসল ত্রুটি ধরা পড়েছে কেবল এ কারণেই যে মাপটি আসল সার্ভারে আসল ডেটা নিয়ে চালানো হয়েছিল। উৎসে যে তিনটিই লেখা আছে, এগুলো সেই তিনটিই — তালিকাটি সম্পূর্ণ, বেছে নেওয়া নয়।
- 1Debian 13-এ ইনস্টলার ব্যর্থ হয়েছে। মিনিমাল ইমেজে git নেই, তাই ক্লোন একেবারেই ভেঙে গেছে। ঠিক করা হয়েছে।
- 2API সারিগুলোতে টেস্ট হারনেস কিছুই মাপছিল না। এর রিকোয়েস্ট হেডারগুলো ভেঙে যাচ্ছিল, তাই প্রতিটি API সারিতে শূন্য নমুনা ছাপা হচ্ছিল — চুপচাপ, তিনটি মেশিনেই। ঠিক করা হয়েছে, আর যে রানে কোনো নমুনা জমা হয় না সেটি এখন চুপচাপ ফল ছাপার বদলে জোরেশোরে জানিয়ে দেয়।
- 3PHP মেমরি লিমিট নিয়ে দুটি স্ক্রিপ্ট একমত ছিল না, অথচ একটি কমেন্টে দাবি করা ছিল যে সূত্র দুটি হুবহু মেলে। সংশোধন করা হয়েছে।
এই অংশটি পেজে থেকে যাবে। এটিই প্রমাণ যে মাপটি আসল ছিল।
আপনার যা লাগবে
আপনার যা লাগবে, আর একটি নতুন ইনস্টলে আসলে যা লাগে
| শর্ত | বিবরণ |
|---|---|
| অপারেটিং সিস্টেম | Ubuntu 26.04 (প্রস্তাবিত), Ubuntu 24.04 (বিকল্প), Debian 13, বা Debian 12। আর কিছু নয় — পুরোনো রিলিজ ও অন্য ডিস্ট্রিবিউশন কিছু নামানোর আগেই নাম ধরে ফিরিয়ে দেওয়া হয়। Debian 12-এর ফ্রি নিরাপত্তা সাপোর্ট জুলাই 2026-এ শেষ হয়েছে। |
| প্রসেসরের ধরন | x86_64, বা arm64 (aarch64 নামেও লেখা হয়)। |
| CPU কোর | একটি দোকানের জন্য 2টি কোরই স্বস্তিকর মাপ। Autotune 1 কোর থেকে 16 কোর পর্যন্ত সমর্থন করে। |
| RAM | 2 GB বাস্তবিক সর্বনিম্ন। ইনস্টলার প্রায় 1.2 GB-র নিচে ফিরিয়ে দেয় আর 2 GB-র নিচে সতর্ক করে। একটি দোকানের জন্য 4 GB স্বস্তিকর মাপ। |
| ডিস্ক | ইনস্টলারের কোনো শর্ত এটি নয়। মাপা তিনটি মেশিনের প্রতিটিতেই ছিল 79 GB। যে আপলোডের পরে 2 GB আর ডিস্কের 10 %-এর মধ্যে যেটি ছোট, তার চেয়েও কম ফাঁকা থাকবে, প্যানেল সেটি ফিরিয়ে দেয়। কনটেইনার ছাড়া নেটিভ 6amMart ইনস্টলের জন্য SixPreflight 20 GB ফাঁকা চায় আর 40 GB পছন্দ করে। |
| সার্ভারের অবস্থা | নতুন। aaPanel, CloudPanel, cPanel বা Plesk নয়। 80 বা 443 পোর্টে আগে থেকে কিছু চলছে না। |
| আপনার প্রোভাইডারে খোলা পোর্ট | ঠিক তিনটি: আপনার প্যানেল পোর্ট (ইনস্টলের সময় বেছে নেওয়া একটি র্যান্ডম বড় সংখ্যা), 80, আর 443। আর কখনোই কিছু নয়। |
| অ্যাক্সেস | সার্ভারের root লগইন। ইনস্টলার অন্য কারও হয়ে চলতে অস্বীকার করে। |
| আপনার কোড | একটি প্রাইভেট git রিপোজিটরিতে আপনার 6amMart কোড। SixPanel git থেকে ইনস্টল করে, zip থেকে নয়। |
| আপনার ফোন | একটি অথেনটিকেটর অ্যাপ। মালিকের অ্যাকাউন্টে দুই-ধাপের লগইন বাধ্যতামূলক আর তা বন্ধ করা যায় না। |
| একটি ডোমেইন | আর তার DNS রেকর্ড সম্পাদনার সুযোগ। |
| দ্বিতীয় একটি দোকান | প্রতিটি বাড়তি দোকানের জন্য মোটামুটি 2 GB বেশি RAM আর 1–2টি বেশি কোর। ওই পরিসরের উপরের দিকটাই ধরুন — 2টি কোর — এটিই সাবধানী দিক। |
| এতে কী খরচ | কিছুই না। SixPanel ফ্রি এবং CodeCanyon-এ প্রকাশিত, আর প্রথম ইনস্টলেশন ও সেটআপও ফ্রি। কোনো লাইসেন্স সার্ভার নেই, নবায়ন করার কোনো কী নেই, আর ইনস্টল কমান্ডে কোনো পারচেজ কোডও নেই। |
SixPanel যা বসায়: nginx, PHP-FPM, MariaDB, Redis আর একটি Node.js প্যানেল সার্ভিস — সবই systemd-র অধীনে এবং সবই রিলিজের নিজের ডিস্ট্রিবিউশন আর্কাইভ থেকে — Ubuntu 26.04-এ PHP 8.5 সঙ্গে MariaDB 11.8, Debian 13-এ 8.4 সঙ্গে 11.8, Ubuntu 24.04-এ 8.3 সঙ্গে 10.11। Docker রানটাইম একই স্ট্যাক কনটেইনার হিসেবে বসায়, PHP 8.4 আর MariaDB 10.11-এ আটকানো। প্যানেল ইন্টারফেসের ভাষা: 8টি — ইংরেজি, স্পেনীয়, আরবি, পর্তুগিজ, ফরাসি, জার্মান, ইন্দোনেশীয়, বাংলা।
একটি নতুন ইনস্টলে আসলে কত সময় লাগে — সৎ সময়রেখা
“পাঁচ মিনিট” হলো ইনস্টল কমান্ড, পুরো কাজ নয়। ইনস্টল কমান্ড প্রায় পাঁচ মিনিট। ভাড়া করা সার্ভার থেকে চালু দোকান পর্যন্ত পৌঁছাতে প্রায় এক ঘণ্টা।
| ধাপ | সময় |
|---|---|
| আপনার কোড একটি প্রাইভেট git রিপোজিটরিতে রাখুন (একবারই, আপনার নিজের কম্পিউটারে) | git কখনো ব্যবহার না করে থাকলে প্রায় 20 মিনিট |
| সার্ভার আপডেট করুন আর তিনটি ছোট টুল যোগ করুন | এক-দুই মিনিট |
| ইনস্টল কমান্ড চালান — এটি সিস্টেম পরীক্ষা করে, Docker বসায়, স্বাক্ষর যাচাই করে, ফাইল নামিয়ে মিলিয়ে দেখে, পাসওয়ার্ড তৈরি করে, একটি র্যান্ডম প্যানেল পোর্ট বেছে নেয়, মেশিন অনুযায়ী সবকিছুর মাপ ঠিক করে, তারপর বিল্ড করে চালু করে | তিনটি অপারেটিং সিস্টেমে মাপা 273–303 সেকেন্ড — প্রায় পাঁচ মিনিট |
| আপনার হোস্টিং প্রোভাইডারের ড্যাশবোর্ডে তিনটি পোর্ট খুলুন | কয়েক মিনিট |
| প্রথম লগইন, আর ফোনে দুই-ধাপের লগইন সেট করা | কয়েক মিনিট |
| ডোমেইন যুক্ত করুন আর ফ্রি সার্টিফিকেট নিন | DNS ছড়িয়ে গেলে এক মিনিটেরও কম — DNS রেকর্ডটি আগেভাগে বসিয়ে রাখুন |
| git থেকে আপনার 6amMart কোড ইনস্টল করুন | কয়েক মিনিট |
| প্রথম সার্ভারের মোট সময় | এক ঘণ্টা হাতে রাখুন। সম্ভবত আগেই শেষ হবে। |
ইনস্টলার শেষে যা ছাপে, আর যা আপনাকে সাথে সাথেই সংরক্ষণ করতে হবে: পুরো প্যানেল URL, ইউজারনেম, আর পাসওয়ার্ড। পাসওয়ার্ডটি একবারই দেখানো হয় আর কেবল হ্যাশ হিসেবে রাখা হয় — সেটি আর পড়ে নেওয়া যায় না।
সবচেয়ে সাধারণ ব্যর্থতা ইনস্টল নয়। সেটি হলো হোস্টিং প্রোভাইডারে প্যানেল পোর্ট খোলা না থাকা।
নিরাপত্তা
নিরাপত্তা — কেবল যা দেখানো যায়
এখানকার প্রতিটি বিষয় প্রোডাক্টেই মিলিয়ে দেখা যায়। এখানকার কিছুই সাধারণভাবে নিরাপদ থাকার দাবি নয়। এই দিকের ফাঁকগুলো লুকানো নয়, নিচের সৎ সীমাবদ্ধতার তালিকায় আছে।
প্যানেল পর্যন্ত পৌঁছানোই
- প্যানেল কেবল একটি গোপন ঠিকানার নিচেই উত্তর দেয়। বাকি সবকিছুতে একটি ফাঁকা “not found” পেজ ফেরে, তাই একটি পোর্ট স্ক্যানার প্যানেলকে বন্ধ পোর্ট থেকে আলাদা করতে পারে না। প্যানেল পোর্টটিও ইনস্টলের সময় বেছে নেওয়া একটি র্যান্ডম বড় সংখ্যা, প্রতিটি সার্ভারে আলাদা।
- গোপন ঠিকানাটি লগইনের সামনে একটি গেট, লগইনের বিকল্প নয় — ইউজারনেম, পাসওয়ার্ড ও দুই-ধাপের কোড সবই তার পেছনে চলে।
- ভুল এন্ট্রি কোড ধ্রুব সময়ে মেলানো হয়, আর একটি নির্দিষ্ট 200 ms দেরির পরে অন্য সবকিছুর মতোই ফাঁকা “not found” দিয়ে উত্তর দেওয়া হয়। এটি প্রতি-ঠিকানার লকআউটে গোনা হয়। একসাথে 32টি ভুল পর্যন্ত এই দেরি থাকে; ওই সীমার পরে “not found” সাথে সাথেই ফিরে আসে। অর্থাৎ ওই সীমা পর্যন্ত একটি ভুল কোডের খরচ অন্য সবকিছুর সমান, সবসময় নয় — যেভাবেই হোক, 15 মিনিটে 20টি ভুল কোড ঠিকানাটিকে 30 মিনিটের জন্য লক করে দেয়।
- নতুন ইনস্টলে লগইন নামটি তৈরি করে দেওয়া হয় — admin-এর সাথে চারটি র্যান্ডম অক্ষর, যেমন admin7f3q — তাই কোনো রোবট লগইন পেজ পেলেও লক্ষ্য করার মতো নাম পায় না। যে ইনস্টলে আগে থেকেই একটি পাসওয়ার্ড হ্যাশ ছিল, সেখানে সাধারণ নাম admin থেকে যায়।
- ঐচ্ছিক প্যানেল-ডোমেইন লক। প্যানেল ডোমেইন সেট করা থাকলে সার্ভারের IP ঠিকানায় সরাসরি রিকোয়েস্ট করলেও সেই একই ফাঁকা “not found” মেলে। ফিরে ঢোকার পথ SSH।
সাইন ইন করা
- পাসওয়ার্ড হ্যাশিং (bcrypt), একটি সাইন করা সেশন কুকি, আর দুই-ধাপের কোড, যা মালিকের অ্যাকাউন্টে বন্ধ করা যায় না।
- রিস্টার্টেও টিকে থাকা একটি লকআউট: 15 মিনিটে 20টি ভুল পাসওয়ার্ড ওই ঠিকানাটিকে 30 মিনিটের জন্য লক করে। পাঁচটি ভুল দুই-ধাপের কোডও একই কাজ করে।
- লগইন ফর্মে ঐচ্ছিক একটি IP অনুমোদিত তালিকা — আর যে তালিকায় আপনার নিজের ঠিকানা নেই সেটি সেভ করতে দেওয়া হয় না, যাতে আপনি নিজেই আটকে না যান।
প্যানেল যা করতে অস্বীকার করে
- প্রতিটি রুটে ডিফল্ট-ডিনাই, সাথে প্রতিটি পরিবর্তনে একটি ক্রস-সাইট-রিকোয়েস্ট পরীক্ষা। ডিপ্লয় webhook একমাত্র ব্যতিক্রম, আর সেটি কাঁচা রিকোয়েস্ট বডির উপর একটি স্বাক্ষর দিয়ে নিজেকে প্রমাণ করে। একই ডেলিভারি দুবার এলে, কিংবা পাঁচ মিনিটের পুরোনো ডেলিভারি এলে সেটি উপেক্ষা করা হয়, আর প্রতিটি প্রত্যাখ্যান অ্যাক্টিভিটি লগে লেখা হয়।
- File manager stack পৌঁছাতে পারে না। Fenced দুটি folder — admin এবং upload।
- বিশ্বাসের সিদ্ধান্ত নেওয়া হয় আসল নেটওয়ার্ক পিয়ার দেখে, ক্লায়েন্ট লিখতে পারে এমন কোনো হেডার দেখে কখনোই নয়।
- কেস-সেনসিটিভ রাউটিং প্রথম মিডলওয়্যারের আগেই বসানো হয়, যা একটি আসল বাইপাস বন্ধ করেছে, যেখানে ভিন্নভাবে বড়-হাতের অক্ষর দেওয়া একটি পাথ কেস-সেনসিটিভ অথেনটিকেশন পরীক্ষা এড়িয়ে যেত।
গোপন তথ্য
- প্যানেলের স্টেট ফাইল কেবল মালিকের জন্য (0600), আর তা আছে কেবল-মালিকের একটি ফোল্ডারে। স্ট্যাক সেটিংস ফাইল 0600। কমান্ড-লাইন সকেটটি কেবল-মালিকের একটি Unix সকেট — ফাইল পারমিশনে কেবল root, নেটওয়ার্কে কখনোই খোলা নয়।
- প্রথম-boot password hash, তারপর blank setting file থেকে ও remove।
- উইজার্ড দিয়ে ইনস্টল করলে আগে অ্যাপ্লিকেশন সেটিংস ফাইল সবার পড়ার মতো থেকে যেত, আর সেটি একটি অরক্ষিত ক্যাশের সাথে কথা বলত। সেটি ঠিক করা হয়েছে — এখন প্রতিটি ইনস্টল, আপডেট, রোলব্যাক ও ট্রান্সফারে অবকাঠামোর কি-গুলো আবার বসানো হয় আর ফাইলটি আবার 0600-এ লক করা হয়।
- ট্রান্সফারে ব্যবহৃত SSH পাসওয়ার্ড কখনো প্রসেস তালিকায় আসে না। সেগুলো এনভায়রনমেন্টের মধ্য দিয়ে যায় আর প্রতিটি লগ লাইন থেকে মুছে দেওয়া হয়।
- সাপোর্ট বান্ডল লেখার আগেই ছেঁকে নেওয়া হয় — সেটিংস কেবল কি-র নামে নামিয়ে আনা হয়, প্যানেলের নিজের স্টেট ফাইল একেবারেই নেওয়া হয় না, আর গোপন এন্ট্রি কোড ও পাসওয়ার্ডের মতো দেখতে মানগুলো ঢেকে দেওয়া হয়।
একটি দোকান অন্য দোকান ডেটা-র out রাখা
- প্রতিটি project এর নিজস্ব unix user হিসাবে চলে, 0700 application folder এবং একটি isolated cache socket সঙ্গে।
- প্রতিটি project এছাড়াও এর নিজস্ব database user grant-এ scoped তার নিজের schema-তে।
- এটি পরীক্ষা করা হয়েছিল এটি ঘোষণা বরং আক্রমণ করে। প্রতিটি cross-project পড়া একটি gate checked যেখানে reject করা হয়।
- PHP additionally confined kernel mount namespace।। shared temp clear।
- দুটি আরও proposal reject measurement দ্বারা shipped না
- একটি-shared-cache সমস্যা এটি replace ছিল real এবং full describe।
রিলিজ — আর যে একটি আপডেট পথ যাচাই করা নয়
- রিলিজ আর্টিফ্যাক্ট সাইন করা, আর সাইনিং কি অফলাইনে থাকে। প্যানেলের Settings → self-update আপনার সার্ভারে পিন করা একটি কি-র সাথে স্বাক্ষর মিলিয়ে দেখে, ইনস্টল করা বিল্ড নম্বরের সমান বা কম হলে ফিরিয়ে দেয়, আর ফাইলের হ্যাশও মিলিয়ে দেখে।
- ইনস্টল কমান্ডটি চালানোর আগে সেটি এনে একটি প্রকাশিত ফিঙ্গারপ্রিন্টের সাথে মিলিয়ে দেখা হয়। ডাউনলোড করা ফাইলটি না মিললে কমান্ড থেমে যায় এবং কিছুই ইনস্টল হয় না।
- অর্থাৎ: তিনটি আপডেট পথের দুটি সিগনেচার-যাচাই করা — প্যানেলের Settings → সেল্ফ-আপডেট, আর ইনস্টল কমান্ড।
- ইনস্টলারটিও যাচাই করা হয়, শুধু সে যে রিলিজ প্রয়োগ করে সেটিই নয়। আপনার সার্ভার ইনস্টলারের ফিঙ্গারপ্রিন্টের প্রকাশিত রেকর্ড পড়ে, ফাইলটিকে তার সঙ্গে মিলিয়ে দেখে, এবং যা মেলে না তা চালাতে অস্বীকার করে — ফলে বদলে দেওয়া বা প্রক্সি করা কোনো আপডেট হোস্ট আপনার সার্ভারকে পরিবর্তিত ইনস্টলার ধরিয়ে দিতে পারে না।
- নতুন সাইনিং কী তখনই গ্রহণ করা হয় যখন আপনার সার্ভারে আগে থেকেই পিন করা কী নিজে সেটিতে সই করেছে — কখনোই আপডেট সার্ভিস বলেছে বলে নয়, আর কখনোই নতুন কী যে রিলিজের সঙ্গে এসেছে তাতে সই করেছে বলেও নয়। ওই দুটোই একটি আপস হওয়া হোস্ট তৈরি করতে পারে; কিন্তু পুরনো কী দিয়ে এমন এক কী-তে সই, যা সে কখনো দেখেনি, সেটি পারে না। এটাই কাউকে আপনার সার্ভারের কী বদলে দেওয়া থেকে ঠেকায়।
একটি মাপা আক্রমণ, সীমা বাঁধা ও আবার মাপা
এই পেজের নিরাপত্তার প্রমাণ এটিই, কারণ এর দুই দিকেই সংখ্যা আছে।
এর সবই মাপা হয়েছে দুই-প্রকল্পের একটি 8 GB টেস্ট মেশিনে, যেখানে Redis-এর সীমা 476 MB। উপরের অপারেটিং-সিস্টেম রাউন্ডের 4 GB মেশিনগুলো থেকে এটি আলাদা মেশিন — ওই রাউন্ডে কেবল 4 GB মেশিনই মাপা হয়েছিল, আর দুটি কথাই সত্য। ফিক্সের পরের রানগুলো চালানো হয়েছে লিস্টিং বাজেট জোর করে 64 MB করে, যা সবচেয়ে ছোট সমর্থিত মেশিন পায়, একটি 8 GB মেশিন সাধারণত যে 245 MB পেত তা নয়।
ফিক্সের আগে
| মাপ | মান |
|---|---|
| ওই মেশিনে Redis-এর মেমরি সীমা | 476 MB |
| সবচেয়ে বড় পেজ সাইজে (limit=200) একটি আইটেম-সার্চ এন্ট্রি | 917,704 bytes |
| প্রতি এন্ট্রিতে লেখা কপি | 2 — একটি লাইভ কি আর পুরো মাপের একটি স্টেল যমজ |
| ওই পেজ সাইজে এক-অক্ষরের 20টি সার্চ | 4.8 সেকেন্ডে +34.2 MB — মাপা, অর্থাৎ প্রতি শব্দে প্রায় 1.71 MB |
| পুরো ক্যাশ সার্ভার ভরতে যত রিকোয়েস্ট লাগে | 476 ÷ 1.71 ⇒ প্রায় 278, একটি সংযোগে মোটামুটি 67 সেকেন্ড |
| সাইন-ইন করা ক্রেতার সেশন | সরে গেছে — চুপচাপ সাইন আউট |
হিসাবের নোট, কারণ এই পেজ উপরে অসম্ভব সংখ্যা ধরাকে গুণ বানিয়ে তারপর এমন টেবিল ছাপতে পারে না যা নিজের গুণই মেলায় না। ভেতরের রিপোর্টে প্রতি শব্দে খরচ লেখা 1.79 MB আর ভরতে লাগে প্রায় 279টি রিকোয়েস্ট। একটি থেকে অন্যটি আসে না: 917,704 × 2 = 1,835,408 bytes = 1.835 MB, 1.79 MB নয়, আর 476 ÷ 1.79 = 265.9, 279 নয়। যে সারিটি সবকিছু মেলায় সেটি মাপা সারিটিই — 20টি সার্চে খরচ 34.2 MB, অর্থাৎ প্রতিটিতে ঠিক 1.71 MB, আর 476 ÷ 1.71 = 278.36, নিচের দিকে কেটে 278; এখানে কিছুই উপরে রাউন্ড করা হয়নি। এটি বলা সময়ের সাথেও মেলে: 20টি রিকোয়েস্টে লেগেছে 4.8 s, তাই 278টিতে লাগে 66.7 s ≈ উৎসে বলা 67 সেকেন্ড। এই পেজ সেই হিসাবের শৃঙ্খলই ছাপে যা একজন পাঠক মিলিয়ে দেখতে পারেন, আর 1.79 MB ও 279 পুনরাবৃত্তি না করে বাদ দেয়।
ফিক্সের পরে — প্রমাণ ফাইলে ছক করা তিনটি ফ্লাড, যার একটিতে কিছুই জমা হয় না
প্রমাণ ফাইলে তিন-সারির একটি টেবিলের উপরে লেখা আছে “ছয়টি একসাথে চলা লগইন-ছাড়া ফ্লাড”, আর দুটির মিল কোথাও মেলানো হয়নি। এর মানে ছয়টি ফ্লাড প্রসেস তিনটি ছক করা ফল দিয়েছে, নাকি ছয়টি রানের তিনটি রিপোর্ট করা হয়েছে, উৎস তা বলে না — তাই এই পেজ বলে “উৎস যে তিনটির কথা বলে” আর সম্পূর্ণতার কোনো দাবি করে না।
| ফ্লাড | জমা হওয়া এন্ট্রি | Redis-এ লিস্টিং বাইট | এভিকশন | সেশন |
|---|---|---|---|---|
| সবচেয়ে বড় পেজ সাইজে (limit=200) 200টি রিকোয়েস্ট | 0 | 0 | 0 | টিকে আছে |
| 50-সারির পেজ সাইজে 500টি রিকোয়েস্ট | 206 | 51.5 MB | 0 | টিকে আছে |
| 50-সারির পেজ সাইজে 2,000টি রিকোয়েস্ট | 207 | 51.8 MB | 0 | টিকে আছে |
ওই ফ্লাডগুলোতে Redis সব মিলিয়ে সর্বোচ্চ পৌঁছেছে তার 476 MB-র মধ্যে 53.6 MB-তে। ওই সংখ্যাটি পুরো ইনস্ট্যান্সের, লিস্টিং পরিবারের নয়: উপরের টেবিলে লিস্টিং বাইটের সর্বোচ্চ 51.8 MB, তাই 53.6 MB লিস্টিং ক্যাশ হতে পারে না।
সবচেয়ে ছোট সমর্থিত মেশিনে 128 MB-র Redis ইনস্ট্যান্সের মধ্যে লিস্টিং পরিবারের সীমা 64 MB। প্রতি সেশনে মোটামুটি 1 KB ধরলে তাতে প্রায় 60,000 জন সাইন-ইন করা ক্রেতার জায়গা থাকে — তবে ওই জায়গায় ওই মেশিনে Redis-এর বাকি সব কাজও থাকে, তাই একে আসনের সংখ্যা নয়, ফাঁকা জায়গার একটি হিসাব ধরুন।
প্যানেলটি আসলে কী, সোজা কথায়
প্রোডাক্টের নিজের ডকুমেন্টেশন যে তিনটি কথা বারবার বলে।
- Panel root-equivalent মেশিনে, construct by: এটি install package, restart service, reboot।
- গোপন এন্ট্রি ঠিকানাটি একটি গেট। লগইন তার পেছনে চলে, আর প্রতিটি লগইনে একটি পাসওয়ার্ড ও একটি দুই-ধাপের কোড লাগে।
- অ্যাডমিন অ্যাকাউন্ট ঠিক একটিই আর কোনো রোল নেই। ভাগাভাগি হয় অস্থায়ী লগইন আর একটি রিড-অনলি ডেমো লগইন দিয়ে।
আমরা কীভাবে পরীক্ষা করি
দুটি স্বাধীন রাউন্ড বলেছে "প্রস্তুত নয়"। এখানে তারা খুঁজে পেয়েছে।
বেশিরভাগ সফটওয়্যার পৃষ্ঠা আপনাকে বলে পণ্য কী করে। এটি এছাড়াও বলে কী ছিল এর আগে মিথ্যা।
- যত রুট চালিয়ে দেখা হয়েছে, পাঁচটি স্ক্রিন আকারে আলো ও অন্ধকার মোডে 283টি পেজ লোড
52
যত রুট চালিয়ে দেখা হয়েছে, পাঁচটি স্ক্রিন আকারে আলো ও অন্ধকার মোডে 283টি পেজ লোড
- যত ইন্টারফেস টেক্সট কি মিলিয়ে দেখা হয়েছে, 7টি ভাষার প্রতিটিতে
2,740
যত ইন্টারফেস টেক্সট কি মিলিয়ে দেখা হয়েছে, 7টি ভাষার প্রতিটিতে
- Panel workflow চালিত end-to-end, উভয় 6amMart codebase-এ
34
Panel workflow চালিত end-to-end, উভয় 6amMart codebase-এ
- স্বাধীন রাউন্ড যার সিদ্ধান্ত ছিল "প্রস্তুত নয়"
2
স্বাধীন রাউন্ড যার সিদ্ধান্ত ছিল "প্রস্তুত নয়"
একটি theme চলেছে প্রতিটি serious finding জুড়ে
প্রতিটি worst defect একটি green surface ছিল ভাঙ্গা জিনিসের উপরে। একটি পৃষ্ঠা বলে "সাফল্য" কিন্তু নিচে কোনো ডেটা ছিল না।
Integration testing — পরীক্ষা কারণ এটি এক্সপোজ করে
এগুলো আমাদেরই, এগুলো গুরুতর ছিল, আর এগুলো ঠিক করা হয়েছে। বিস্তারিত দেখতে যে-কোনোটি খুলুন।
Backup চলছিল, সাফল্য রিপোর্ট করছিল, এবং কোনো ডেটাবেস ছিল নাঠিক করা
backup tool-র exclude rule পুরো run filter করেছে, তাই কাজ করার ডিরেক্টরি exclude করা একই run ছিল যা স্পষ্টভাবে নাম দিয়েছিল dump ফাইল বাতিল করেছে। tool খালি ডিরেক্টরি সংরক্ষণ এবং সফলভাবে বেরিয়ে এসেছে।
ছয়টি স্ন্যাপশট — যার একটিতে ডেটাবেস ব্যাকআপের ট্যাগ ছিল — ধরে রেখেছিল 10,888টি ফাইল আর একটিও ডেটাবেস ডাম্প নয়, অথচ Backups পেজ সারাক্ষণ সাফল্য আর একটি রিপোজিটরি আকার দেখিয়ে গেছে।
এটি লুকিয়ে ছিল কারণ সাপ্তাহিক শিডিউলের বিপরীতে যাচাইয়ের থ্রেশহোল্ড ছিল 21 দিন। দুটিই ভুল ছিল, আর দুটিই এখন সেটিং নয়, গেট।
ঠিক করা হয়েছে, আর তারপর রিস্টোর ধরে নেওয়া হয়নি — প্রমাণ করা হয়েছে: একটি তাজা ব্যাকআপে 39 MB-র একটি ডেটাবেস ডাম্প থাকে, যা 192টি টেবিল আর পুরো 66,701 অর্ডার ফিরিয়ে আনে।
Vendor storefront একটি clone যেটি আপনার key নেই এতে সম্পূর্ণ vendor কাছাকাছি থেকে কাজঠিক করা
একটি vendor storefront একটি git URL clone করে সরাসরি একটি Composer dependency হিসাবে।
যদি সেই সম্পত্তি একটি fork, এটি একটি vendor গেটওয়ে এর বিপরীতে authentication check করে যা পূর্বে থেকে একটি install key সংরক্ষণ করেছে।
Fix: zip থেকে install করুন এবং authenticate করুন activation wizard।
Deploy, rollback এবং activation code আপডেট করেছে এবং site পুরাতন serve করেছেঠিক করা
SixPanel PHP-র compiled-code cache pinned রাখে — একটি deliberate, পরিমাপ করা গতি পছন্দ — যার মানে deploy মধ্যে code পুরাতন বৈধ থাকে।
তাই একটি deploy pulled নতুন code, database migration চালিয়েছে, rebuilt cache এবং restarted worker কিন্তু serve করেছে পূর্ববর্তী।
প্রমাণিত বরং argued, প্রকৃত ওয়েব সার্ভার মাধ্যমে একটি file ইতিমধ্যে cached: সম্পাদন আগে রিলোড করার পরে।
চার সাইটে ঠিক করা। পাঠ রেখেছে: পারফরম্যান্স সেটিং যা discipline উপর নির্ভর করে কোথাও একটি check ছাড়া।
একটি দোকান অন্যটির payment এবং email secret পড়তে পারত shared cache-এর বাইরেঠিক করা
Cache একটি একক shared service ছিল একটি password পিছনে যে প্রতিটি project-র setting file ধারণ করে।
Fix একটি cache instance per project, তার নিজস্ব socket-এ, তার নিজস্ব directory-তে, তার নিজস্ব password-এ।
প্রমাণিত আক্রমণ ফিরিয়ে আনতে: probe succeeding থেকে refuse করা উভয় দিকে।
মাপা খরচ: প্রতি প্রজেক্টে 3.2 MB মেমরি। 20টির মধ্যে 18টি সার্ভার-ও-প্রজেক্ট সংযোগে PHP ওয়ার্কারের সংখ্যা অপরিবর্তিত, আর যে নেটওয়ার্ক লুপব্যাকের জায়গা নিয়েছে socket আসলে তার চেয়ে দ্রুত। লাইভ ডেটা সরাতে লেগেছে 13.9 মিলিসেকেন্ড, আর কাউকে সাইন-আউট করতে হয়নি।
.env overwritten একটি deployment করার সময় বা পুরানো code serve করা হয়েছেঠিক করা
একটি fresh install git থেকে code pull করে। Deployment script সেট করে শুধুমাত্র .env পুনর্নির্দেশিত সেট করে একটি output directory-তে pull করার আগে।
যদি .env ভুল values রাখে (যেমন শেষ গ্রাহক থেকে), pull পরবর্তী develop সাফল্যের সাথে থাকে কিন্তু application এখনও পূর্ববর্তী credentials ব্যবহার করে চলছে।
এটি মিস করা হয়েছিল কারণ আমরা script পরে কার্যকরভাবে কল করিনি এবং application একটি browser থেকে, PHP থেকে শুরু নয়।
Fixed, এবং এখন shell-র জন্য একটি trap ব্লক লেখে যা .env মুছে pull করার আগে।
একটি পার্শ্ব প্রভাব: pull করা কখনও কখনও একটি file নাম যা একটি git symbolic reference সমাধান করে যা পূর্ববর্তী ছিল। যদি সেই file আপনার .env সংরক্ষণ করে, file replace করে deployment।
Untouched CodeCanyon 6amMart-এ, install সমাপ্ত এবং অ্যাডমিন প্যানেল অব্যবহারযোগ্য ছিলঠিক করা
Vendor 6amMart এর অ্যাডমিন প্যানেল login এর পরে একটি purchase-code activation ধাপের পিছনে লক করে। SixPanel কখনও code চাইনি, কখনও উল্লেখ করেনি, এবং deployment সমাপ্ত রিপোর্ট করেছে।
এটি দীর্ঘ সময়ের জন্য অদৃশ্য থেকেছে কারণ আমাদের নিজের 6amMart optimised অনুলিপি সেই check অক্ষম করেছে, তাই পণ্যের পুরো test ইতিহাস একটি codebase বিরুদ্ধে চলেছে যেখানে gate বিদ্যমান নেই।
wizard এখন purchase code সংগ্রহ করে এবং application-র নিজস্ব activation সম্পন্ন করে। একটি trap বন্ধ করা হয়েছে: application licence server সম্পূর্ণরূপে skips যখন অনুরোধ মেশিন থেকে আসে, যা একটি command-line অনুরোধ করে, তাই যেকোনো আবিষ্কৃত code কোনো packet সার্ভার ছাড়াই গৃহীত হত।
দুটি সম্পর্কিত জিনিস সঙ্গে ঠিক করা হয়েছে। storefront এখন zip থেকে ইনস্টল করে একটি CodeCanyon ক্রেতা আসলে, git repository প্রয়োজন বরং। এবং vendor project আর development মোডে deployed না, যা login captcha-র নিজস্ব উত্তর মুদ্রিত করেছে।
Install একটি unsigned tool করেছে যা signature নিজেই verify করতে পারে নাঠিক করা
SixPanel একটি file artifact_sign signature করে এবং একটি manifest generate করে যা سلام ও updates list করে।
Deploy একটি install নতুন signature verify করে এবং একটি checksum compare করে সমস্ত file যা দাবি করা হয়েছে।
একটি attacker একটি vendor file এর একটি copy patch করতে পারে, re-sign করতে পারে একটি নকল key সঙ্গে এবং install নতুন ও পুরানো signature সহ।
Deployment একটি graceful shutdown গ্রেস period অপেক্ষা করেছে যা একটি অপ্টিমাইজেশন দেখায় নাঠিক করা
যে সার্ভারকে অপারেটিং সিস্টেম নিজেই অবনত বলছিল, সেখানে “সার্বিকভাবে সুস্থ” — হেলথ কোডের কিছুই কখনো তাকে জিজ্ঞেসই করেনি। রিলিজ সার্ভারে একটি নির্ধারিত সার্ভিস একদিন ধরে প্রতি 60 সেকেন্ডে ব্যর্থ হচ্ছিল, তার ব্যর্থতার হুক 1,440 বার চালাচ্ছিল, অথচ শিরোনামে লেখা ছিল সুস্থ।
সেলফ-হিলিং এমন একটি চেককে স্বাস্থ্যের পর্যবেক্ষণ ধরে নিচ্ছিল, যেটি আদৌ চলতেই পারেনি। দুটি এরর গণনার মধ্যে 135 গুণ অমিল। ডিস্ক ব্যবহারের হিসাব ব্যবহৃত জায়গার 18.4% ধরে সেটিকে পুরো ছবি হিসেবে দেখানো — এখন 92.7%।
একটি অসমাপ্ত সেটআপ উইজার্ড, যা version এন্ডপয়েন্টটি আদৌ চায়ইনি, আর মোবাইল নেভিগেশন, যা আপডেটের নোটিশ দেখানো অবস্থায় শূন্য প্রস্থে গুটিয়ে যেত।
চব্বিশটিই বন্ধ। শেষ ছয়টি রিপোর্ট করা ত্রুটির দুটি আসলে সত্যিকারের ত্রুটি ছিল না, আর দুটিকেই চেহারা বাঁচাতে ঠিক না করে প্রমাণসহ বাদ দেওয়া হয়েছে।
বসানো প্রতিটি সার্ভার এমন একজন ব্যবহারকারীর মালিকানার ফাইল চালাচ্ছিল, যে সেই মেশিনে নেইঠিক করা
বিল্ড মেশিনের নিজের ব্যবহারকারী আর গ্রুপ আর্টিফ্যাক্টের ভিতরেই ঢুকে গিয়েছিল — একটি সার্ভারে 459টি ফাইল, যার মধ্যে এমন একটিও আছে যেটি কেবল প্রকাশিত ইনস্টল কমান্ডটিই নিয়েছিল।
যেমন ছিল তাতে এটি কাজে লাগানোর মতো ছিল না, কিন্তু এর মানে সিস্টেম এমন কোড চালাচ্ছিল যার মালিক সে নয় — আর এ অবস্থা ফেলে রাখার মতো নয়।
আপডেট নিজেই সেটি শুধরে দিয়েছে: ভুল মালিকের 459টি ফাইল শূন্যে নেমেছে।
যা আপ রাখা হয়েছে
একই রাউন্ড যা supposed worked confirm করেছে, এবং সেগুলি worth stating।
- সম্পূর্ণ reboot
- 79 সেকেন্ডে SSH-এ ফেরত, শূন্য ব্যর্থ সার্ভিস, রিবুটের আগে নেওয়া স্ন্যাপশটের সাথে প্রতিটি সার্ভিস বাইট-হিসেবে অভিন্ন অবস্থায়, দুটি websocket-ই সংযুক্ত, কোনো ম্যানুয়াল ধাপ নেই।
- Panel সম্পূর্ণভাবে মারা
- প্রায় 4 সেকেন্ডে ফেরত।
- একটি সাধারণ আপডেট
- শূন্য সেকেন্ড ডাউনটাইম, পুরো সময়টায় 91-এর মধ্যে 91টি অনুরোধ স্বাভাবিকভাবে উত্তর পেয়েছে।
- ব্যাকআপ থেকে রিস্টোর
- 192টি টেবিল আর 66,701 অর্ডার, পরীক্ষার জন্য বানানো ব্যাকআপ থেকে নয় — একটি আসল নির্ধারিত ব্যাকআপ থেকে।
এখনও খোলা, এবং stated এখানে left out বরং
- নেটিভ সার্ভারে একটি ডেটাবেস কাউন্টার খারাপ পড়ছে — 59.8% কোয়েরিতে টেম্পোরারি টেবিল ডিস্কে লেখা হচ্ছে। এটি মাপ ঠিক না থাকার সমস্যা নয়, কোয়েরির আকৃতির সমস্যা, আর গত রাউন্ডের পর থেকে এটি নতুন।
- Container product একটি release দরকার carry করতে backup fix এবং DNS কাজ উপরে বর্ণিত।
- টেস্ট সার্ভারে পড়ে থাকা একটি পুরোনো ব্যর্থ ব্যাকগ্রাউন্ড জবই একমাত্র কারণ, যার জন্য নিজের চেক-আপে স্কোর 97-এর বদলে 88 এসেছে — কোনো একটি সারি খারাপ থাকলেই স্কোরে ছাদ বসে যায়, আর প্রায় একশো চেকজুড়ে ভেতরের কাঁচা স্কোরের পার্থক্য মাত্র 0.03।
এটি সার্ভার সফটওয়্যারের জন্য অস্বাভাবিক কিছু নয়। যা অস্বাভাবিক তা এটি প্রকাশ করা। যদি একটি panel-এর বিপণন পৃষ্ঠা এর মতো কোনো তালিকা নেই, তার মানে খুঁজে পাওয়ার কিছু ছিল না।
সৎ সীমাবদ্ধতা
সৎ সীমাবদ্ধতা
এর প্রতিটিই আজ সত্য।
- 1
এটি পুরো সার্ভারটাই নেয়।
অন্য কোনো ওয়েবসাইট নয়, অন্য কোনো কন্ট্রোল প্যানেল নয়, 80 ও 443 পোর্টে আর কিছু নয়।
- 2
একটি অ্যাডমিন অ্যাকাউন্ট। কোনো রোল নেই, টিম অ্যাকাউন্ট নেই।
ভাগাভাগির উপায় হলো অস্থায়ী লগইন আর একটি রিড-অনলি ডেমো লগইন।
- 3
প্যানেলটি মেশিনে root-এর সমান।
যে-ই এতে লগইন করতে পারে, সে ওই সার্ভারে যা খুশি চালাতে পারে। সার্ভার প্যানেল জিনিসটাই এমন। Docker রানটাইমে রিবুট, অপারেটিং সিস্টেম আপডেট আর সেলফ-আপডেট উপরন্তু এমন একটি প্রিভিলেজড কনটেইনার চালিয়ে কাজ করে, যা হোস্টের ফাইলসিস্টেমে ঢোকে।
- 4
রিস্টোর এখনও “যেকোনো সার্ভারে সরান” বোতাম নয়।
একটি ব্যাকআপ রান প্রতিটি প্রকল্প ঢাকে, কিন্তু রিস্টোর এখন ডিফল্ট প্রকল্পকেই লক্ষ্য করে। অন্য মেশিনে রিস্টোর করলে পুরোনো মেশিনের পাসওয়ার্ড ও পাথ থেকে যায়, আর আপনি Update না চাপা পর্যন্ত অ্যাপ্লিকেশন কানেক্ট করতে পারে না। রিস্টোর কাজটি ডেটাবেস মাইগ্রেশনও চালায় না, তাই নতুন কোডের নিচে পুরোনো ব্যাকআপ স্কিমার পেছনে পড়ে থাকে। দুটিরই হাতে করার একটি ধাপ আছে; আজ কোনোটিই স্বয়ংক্রিয় নয়। 15 আগস্টের রাউন্ডে রিস্টোরের পথটি পড়ে যাচাই করা হয়েছে, চালানো হয়নি।
- 5
কোড রোলব্যাক ডেটাবেস মাইগ্রেশন ফেরায় না।
মাইগ্রেশন চলে গিয়ে থাকলে কোড ফেরাতে ব্যাকআপ রিস্টোর লাগে।
- 6
প্যানেল নবায়ন করা সার্টিফিকেট রিস্টার্টে নেয়।
দৈনিক নবায়ন nginx রিলোড করে; প্যানেল নিজের সার্টিফিকেট বুটের সময় একবারই পড়ে।
- 7
পুরোনো সার্ভার থেকে দোকান সরিয়ে আনা পড়ে যাচাই করা হয়েছে, চালানো হয়নি।
সেটি ছিল 15 আগস্টের রাউন্ড। একে সমর্থিত ধরুন, আপনার ধরনের সার্ভারে প্রমাণিত নয়।
- 8
Self-healing watchdog শুধুমাত্র দেখে service যা health check declare করে।
Container runtime-এ optional websocket এবং storefront container declare করে না health check সঙ্গে।
- 9
প্যানেলের নিজের কোড আপনার সার্ভারে পড়া যায় না।
এর ব্যাকএন্ড V8 বাইটকোড হিসেবে যায় আর বিল্ড থেকে পড়ার মতো সোর্স সরিয়ে দেওয়া হয়; ব্রাউজারের ফাইলগুলো মিনিফাই ও অবফাসকেট করা। এটি সুরক্ষা নয়, প্রতিবন্ধক — যিনি সত্যিই চান তিনি এখনও বের করতে পারবেন এটি কী করে। আপনার 6amMart কোড আর আপনার ডেটায় এতে কোনো হাত পড়ে না।
- 10
sixpanel কমান্ড লাইনের self-update-এ কোনো স্বাক্ষর পরীক্ষা নেই, কোনো হ্যাশ পরীক্ষাও নেই।
প্যাকেজড ইনস্টলে এটি নেটওয়ার্ক দিয়ে ইনস্টলার নামিয়ে root হিসেবে চালায়, আর তার নিজের প্রোগ্রেস লাইন উল্টোটা দাবি করে। প্যানেলের Settings → সেল্ফ-আপডেট আর ইনস্টল কমান্ড যাচাই করা; এই তৃতীয় পথটি নয়। ঠিক হওয়া পর্যন্ত প্যানেল থেকেই আপডেট করুন।
- 11
অ্যাক্টিভিটি লগে একটি ফাঁক আছে, আর ধাপ বাড়ানোর নিয়মগুলো অসম।
একটি নির্ধারিত কাজ মুছলে কোনো অডিট রেকর্ড লেখা হয় না, অথচ তৈরি, সম্পাদনা ও হাতে চালানো — সবই লেখা হয়, তাই প্যানেল-স্তরের একটি root কাজ মুছলে কোনো চিহ্নই থাকে না। আলাদা করে: প্যানেল-স্তরের একটি নির্ধারিত কাজের জন্য আপনাকে পাসওয়ার্ড আবার দিতে হয়, কিন্তু রিবুট, অপারেটিং সিস্টেম আপডেট ও প্যানেলের সেলফ-আপডেট — যেগুলো সবই হোস্টে root — কেবল একটি বৈধ সেশন চায়।
- 12
প্যানেলের তিনটি সেটিং মৃত কনফিগারেশন।
Docker রানটাইমে প্যানেলের API রেট লিমিট, এর ভারী-পথের রেট লিমিট আর আপলোডের আকারের সীমা কোড পড়ে নেয় বটে, কিন্তু প্যানেল কনটেইনারে কখনোই পৌঁছায় না — তাই সেটিংস ফাইলে সেগুলো বদলালে কিছুই বদলায় না। ডকুমেন্টেশনে বলা আছে, কোনো অ্যাডমিনকে এগুলো দেখিয়ে দেওয়া চলবে না।
- 13
Kubernetes নেই।
প্যানেলে কোনো Kubernetes ড্রাইভার নেই।
- 14
PHP-র JIT compiler একটি runtime-এ চালু এবং অন্যটিতে বন্ধ।
SixPanel PHP-র tracing JIT চালায়। aaPanel যে মোড শিপ করে তার বিপরীতে এটি এক অনুরোধে 9-এর মধ্যে 9টি এন্ডপয়েন্টে আর একসাথে চারটিতে 9-এর মধ্যে 9টিতে দ্রুততর মাপা হয়েছে; এই রানটাইমে JIT একেবারে বন্ধ করলে আরও দ্রুত হতো কি না, সেটি পরীক্ষা করা হয়নি। কনটেইনার রানটাইমে JIT বন্ধ, কারণ সেখানে এটি 12-এর মধ্যে 11টি এন্ডপয়েন্টে ধীর মাপা হয়েছে আর দ্বাদশটিতে সমান। একই সেটিং, দুটি স্ট্যাক, উল্টো উত্তর — দুটিই মাপ যা বলেছে তা-ই। অরিজিনে Brotli ও HTTP/3 দুটিতেই ইচ্ছাকৃতভাবে বন্ধ: ওই স্তরটি Cloudflare সামলায়।
- 15
ব্যাকগ্রাউন্ড সারি Redis নয়, ডেটাবেস ব্যবহার করে।
সারির থ্রুপুটে Redis 1.76× দ্রুত মাপা হলেও তা নেওয়া হয়নি, কারণ মেমরির চাপে একটি Redis সারি চুপচাপ সরে যেতে পারে — সারিতে থাকা 50টি কাজ 0-তে নেমে গিয়েছিল, লগে কিছুই ওঠেনি, কোনো এররও হয়নি। অর্ডারের জন্য জরুরি কিছুই সারিতে রাখা হয় না।
- 16
রেট লিমিটিং একটি ফ্লাড শিল্ড, DDoS সুরক্ষা নয়।
পুরো একটি শহর যখন একটি ক্যারিয়ার IP ঠিকানা ভাগ করে, তখন প্রতি-ঠিকানার সীমা নিখুঁত হতে পারে না। এর জন্য আসল স্তর হলো Cloudflare।
SixPanel আর 6amMart
SixPanel হলো সার্ভার। অপ্টিমাইজড কোড হলো 6amMart নিজেই।
SixPanel একটি 6amMart ইনস্টল দ্রুত বসানো, নিরাপদে আপডেট করা আর কম খরচে চালানো সহজ করে।
6amMart-এর নিজের স্ক্রিন দ্রুততর করা আলাদা কাজ, আর সেটি বাড়তি কিছু নয়, ইনস্টলেশন সার্ভিসের সাথেই আসে — একটি লাইভ সার্ভারে প্রতিটি গ্রাহকমুখী স্ক্রিনে 10× থেকে 22× দ্রুত মাপা। ওই স্ক্রিনগুলো 0.5–8.19 s থেকে নেমে এসেছে 45–370 ms-এ।
দুই সেট সংখ্যা আলাদা জিনিস মাপে, আর কখনোই একটি টেবিলে মেশানো হয় না। SixPanel-এর সংখ্যাগুলো সার্ভারের সংখ্যা — একই অ্যাপ্লিকেশন, আলাদা স্ট্যাকে পরিবেশিত। অপ্টিমাইজ করা কোডের সংখ্যাগুলো অ্যাপ্লিকেশনের সংখ্যা — একই স্ট্যাক, আলাদা কোড চলছে। এই রাউন্ডে সবচেয়ে ধীর যা মাপা হয়েছে সেটি এ দুটির কোনোটিই নয়: 6amMart-এর একটি অ্যাডমিন রিপোর্ট 20.9 সেকেন্ডে, যেটি কোনো সার্ভার সেটিং-ই নাড়াতে পারেনি।
অপ্টিমাইজড কোড আলাদা করে কেনার জিনিস নয়। দ্বিতীয় কোনো লাইসেন্স নেই, দ্বিতীয় কোনো দাম নেই, দ্বিতীয় কোনো রিলিজ ধারা নেই — চলতি 6amMart ইনস্টলেশন সার্ভিসটি এভাবেই দেওয়া হয়, একই $300 ইনস্টলে। 6amMart-এর ভেন্ডর নতুন রিলিজ আনলে প্রকাশিত ক্যাটালগ নিয়মটি অপরিবর্তিতই থাকে: নতুন স্ক্রিপ্ট সংস্করণে আপডেট বা আপগ্রেড ইনস্টল দামের 50 %। প্রতিটি ইনস্টল সর্বশেষ 6amMart রিলিজেই যায়।
FAQ
মানুষ আসলে যেসব প্রশ্ন করেন
চৌদ্দটি প্রশ্ন, পৃষ্ঠার বাকি অংশের মতো একই সংখ্যা দিয়ে উত্তর দেওয়া।
SixPanel কী?
এক কাজের জন্য একটি সার্ভার নিয়ন্ত্রণ প্যানেল: আপনার নিজস্ব সার্ভারে একটি 6amMart দোকান চালানো। এটি ওয়েব সার্ভার, ডেটাবেস, PHP, ক্যাশ, background worker, scheduler, websocket সার্ভার এবং HTTPS সার্টিফিকেট ইনস্টল করে, এবং তারপর এর সবকিছু চালানোর জন্য একটি ওয়েব পৃষ্ঠা দেয়। এটি দুটি runtime-এ আসে — যা সরাসরি মেশিনে ইনস্টল করে, যা সুপারিশকৃত, এবং যা container ব্যবহার করে।
SixPanel-এর সাথে কি 6amMart স্ক্রিপ্ট থাকে?
না। 6amMart আপনি CodeCanyon থেকে কেনেন। SixPanel আপনার আগে থেকেই কেনা কোডটি আপনার নিজের প্রাইভেট git রিপোজিটরি থেকে ইনস্টল করে। SixPanel নিজে ফ্রি এবং CodeCanyon-এ আলাদাভাবে প্রকাশিত, আর তার ইনস্টল কমান্ড পাবলিক — সবার জন্য একই।
আমি কোন অপারেটিং সিস্টেম বসাব?
দুটি রানটাইমেই Ubuntu 26.04 LTS। নেটিভ রানটাইম ঠিক তিনটি রিলিজ সমর্থন করে — Ubuntu 26.04, Ubuntu 24.04 ও Debian 13 — আর আপনি যেটি বেছে নেবেন তার থেকেই PHP, MariaDB, nginx ও Redis নেয়। গতি এর কারণ নয়: ছয়টি মাপা অক্ষের কোনোটিতেই সংস্করণ বদলে রিপোর্ট করার মতো পার্থক্য আসেনি। কারণটি নিরাপত্তা আপডেট: 26.04-এ প্যাচ আসবে এপ্রিল 2031 পর্যন্ত, তার বিপরীতে 24.04-এর জন্য মে 2029 আর Debian 13-এর জন্য অগাস্ট 2028। নেটিভ রানটাইম Debian 12-কে নাম ধরে বাতিল করে; কনটেইনার রানটাইম এখনো এতে বসে, কিন্তু এর নিরাপত্তা সাপোর্ট জুলাই 2026-এ শেষ হয়েছে, তাই নতুন দোকান এখানে শুরু করবেন না।
সুপারিশটি গতির বদলে সাপোর্টের বাকি মেয়াদ নিয়ে কেন?
কারণ গতি কিছুই ঠিক করে দেয়নি। অভিন্ন হার্ডওয়্যারে ছয়টি অক্ষ মাপা হয়েছে — অপারেটিং সিস্টেম, PHP, MariaDB, nginx, Redis আর কার্নেল — আর কোনো সংস্করণ বদলে রিপোর্ট করার মতো পার্থক্য আসেনি। বাইট-হিসেবে অভিন্ন দুটি মেশিন 20-এর মধ্যে 20টি সারিতে নিজেদের মধ্যেই 11.6 % অমিল দেখিয়েছে, যা পাওয়া প্রতিটি প্রভাবের চেয়েই বড়। যা সত্যিই আলাদা হয় সেটি হলো, কোন রিলিজ আর কত দিন নিরাপত্তা প্যাচ পেতে থাকবে — আর সাপোর্ট ফুরিয়ে যাওয়া অপারেটিং সিস্টেমই একমাত্র ঘটনা যা পুরো সার্ভার আবার গড়তে বাধ্য করে। তিনটির মধ্যে Ubuntu 26.04 LTS-এর মেয়াদ সবচেয়ে দীর্ঘ, এপ্রিল 2031 পর্যন্ত।
কত ছোট সার্ভার ব্যবহার করতে পারি?
দুটি প্রসেসর কোর আর 4 GB RAM একটি পুরো দোকান চালায় — আমরা এই মাপেই মেপেছি। ইনস্টলার প্রায় 1.2 GB-র নিচে ফিরিয়ে দেয় আর 2 GB-র নিচে সতর্ক করে। দ্বিতীয় বা তৃতীয় দোকানের জন্য প্রতিটিতে মোটামুটি 2 GB বেশি RAM আর 1–2টি বেশি কোর ধরে রাখুন।
এটি কত দ্রুত?
অভিন্ন হার্ডওয়্যারে aaPanel-এর বিপরীতে মাপা — 2 কোর, 4 GB, 66,701 অর্ডারের একই দোকান — SixPanel এক অনুরোধে 1.76× দ্রুত উত্তর দিয়েছে আর চারটি একসাথে এলে 1.82× দ্রুত, দুই মেশিনেই PHP পর্যন্ত পৌঁছানো এন্ডপয়েন্টগুলোতে। aaPanel-কে আগে পূর্ণভাবে টিউন করা হয়েছিল। পুরো টেবিল, পদ্ধতি আর এখনো অব্যাখ্যাত অংশটুকু — সবই উপরে আছে।
ইনস্টলে কত সময় লাগে?
কনটেইনার রানটাইমে নজরদারি ছাড়াই প্রায় পাঁচ মিনিট — তিনটি অপারেটিং সিস্টেমজুড়ে 273 থেকে 303 সেকেন্ড মাপা। নেটিভ রানটাইম একই পদ্ধতিতে সময় ধরে দেখা হয়নি, তাই এটির জন্য কোনো সংখ্যা এখানে ছাপা হচ্ছে না। ভাড়া নেওয়া একটি সার্ভার থেকে চালু দোকান পর্যন্ত পৌঁছাতে — DNS, সার্টিফিকেট আর আপনার কোড বসানোসহ — প্রথম সার্ভারে যেভাবেই হোক প্রায় এক ঘণ্টা লাগে।
একই সার্ভারে কি আমার অন্য ওয়েবসাইট রাখতে পারি?
না। যে সার্ভারে আগে থেকেই aaPanel, CloudPanel, cPanel বা Plesk চলছে, কিংবা 80 বা 443 পোর্টে কিছু আছে, ইনস্টলার সেটি ফিরিয়ে দেয়। SixPanel পুরো মেশিনের ওয়েব সার্ভার, সার্টিফিকেট ও ফায়ারওয়াল পরিকল্পনা সামলায়, আর একই মেশিনে দুটি সিস্টেম সেটি করলে একে অন্যকে ভেঙে দেয়। একই সার্ভারে আরও 6amMart দোকান চালানো সমর্থিত।
পাসওয়ার্ড না দিয়ে কি ডেভেলপারকে অ্যাক্সেস দিতে পারি?
হ্যাঁ। নিজের নাম ও পাসওয়ার্ডসহ একটি অস্থায়ী লগইন তৈরি করুন, যার মেয়াদ 1 ঘণ্টা, 8 ঘণ্টা, 24 ঘণ্টা বা 7 দিন পরে শেষ হয়। এটি দিয়ে সাইটটি চালানো যায়। কে ঢুকতে পারবে তা বদলানো যায় না, আর আপনার গোপন তথ্যও দেখা যায় না। কাউকে প্যানেল দেখানোর জন্য একটি রিড-অনলি ডেমো লগইনও আছে।
SixPanel আপডেট করলে কি আমার ডেটা বা কোডে হাত পড়ে?
না। SixPanel আপডেট করা মানে SixPanel-এর নিজের কোড বদলে যাওয়া। আপনার সেটিংস, আপনার ডেটা — ডেটাবেস, আপলোড, সার্টিফিকেট, স্থানীয় ব্যাকআপ — আর আপনার অ্যাপ্লিকেশনের কোড ঠিক যেমন ছিল তেমনই থাকে। একটি জিনিস জানা দরকার, কারণ আমরা কঠিন পথেই সেটি শিখেছি: ডিস্কে ফাইল পৌঁছে দেওয়া আপডেট আর কার্যকর হওয়া আপডেট এক জিনিস নয়। এখন যে পথই স্টেট লেখে, তাকে ঘোষণা করতে হয় আপডেট সেটি পৌঁছে দেয় কি না, প্রতিটি বিল্ডে একটি পরীক্ষা চলে, আর নতুন বসানো একটি সার্ভার ও আপডেট করা একটি সার্ভার 1,447-এর মধ্যে 1,447টি অভিন্ন কনফিগারেশন লাইন তৈরি করে — সেটি প্রমাণ করা হয়েছে।
ব্যাকআপ সত্যিই কাজ করে, তা আমি কীভাবে জানব?
প্যানেল নিজেই সেটি প্রমাণ করে, আর প্রমাণ করে এ কারণেই যে একবার এটি ভুল হয়ে গিয়েছিল। ব্যাকআপ চলেছিল, সাফল্যের খবর দিয়েছিল, আর চার দিন ধরে তাতে কোনো ডেটাবেসই ছিল না — কারণ টুলের exclude নিয়মটি সেই একই রানে নাম-দেওয়া ডাম্প ফাইলগুলোকেই বাতিল করে দিচ্ছিল। সেটি ঠিক করা হয়েছে, আর এখন এটি সেটিং নয়, একটি গেট: রিস্টোর একটি ফেলে-দেওয়ার ডেটাবেসে তুলে গুনে দেখা হয় আর মুছে দেওয়া হয় — 192টি টেবিল আর 66,701 অর্ডার, একটি আসল নির্ধারিত ব্যাকআপ থেকে। দুটি সৎ সতর্কতা এখনো থেকে যায়: আলাদা একটি সার্ভারে রিস্টোর করলে পরে একটি ম্যানুয়াল ধাপ লাগে, আর রিস্টোর এখন ডিফল্ট প্রজেক্টকেই লক্ষ্য করে।
SixPanel কি ওপেন সোর্স?
না। প্যানেলের ব্যাকএন্ড V8 বাইটকোড হিসেবে যায় আর পড়ার মতো সোর্স সরিয়ে দেওয়া হয়, ব্রাউজারের ফাইলগুলো মিনিফাই করা। আমরা একে নিরাপত্তা নয়, প্রতিবন্ধক বলি — যিনি সত্যিই চান তিনি এখনও বের করতে পারবেন কোডটি কী করে। আপনার 6amMart কোড আর আপনার ডেটা আপনারই, আর এখানকার কিছুই সেগুলো আড়াল করে না। আপনার নিজের সার্ভারে পড়ার মতো সোর্স যদি একটি শর্ত হয়, তাহলে সাধারণ কাজের একটি ওপেন প্যানেলই আপনার জন্য ভালো পছন্দ।
SixPanel এবং SixPanel Docker-এর মধ্যে পার্থক্য কী?
একই প্যানেল, একই কমান্ড আর একই ম্যানুয়াল — কেবল নিচের সফটওয়্যার কীভাবে বসে সেটিই আলাদা। SixPanel nginx, PHP, MariaDB ও Redis সরাসরি রিলিজের নিজের ডিস্ট্রিবিউশন আর্কাইভ থেকে বসায় আর systemd-কে সেগুলো দেখাশোনা করতে দেয়। SixPanel Docker একই স্ট্যাক কনটেইনার হিসেবে চালায়, হোস্টে যা-ই চলুক PHP 8.4 আর MariaDB 10.11-এ আটকানো। মাপা প্রতিটি এন্ডপয়েন্টে নেটিভটিই দ্রুততর, আর সেটি প্রজেক্টগুলোকে PHP-র ভিতরে নয় কার্নেলে আলাদা রাখে, তাই সুপারিশ সেটিই — আর নতুন ডেভেলপমেন্টও ওখানেই যায়। কনটেইনারটি নিন যদি চান স্ট্যাক কনটেইনারে আলাদা থাকুক, কিংবা এমন একটি রিলিজে MariaDB 10.11 দরকার হয় যার আর্কাইভে সেটি নেই।
আপনার পৃষ্ঠা আপনার নিজের পণ্যের defect তালিকা করে। কেন?
কারণ এটি একমাত্র সৎ প্রমাণ যে পরীক্ষা বাস্তব। দুটি স্বাধীন end-to-end রাউন্ড "প্রস্তুত নয়" একটি সিদ্ধান্ত ফেরত দিয়েছে এটি শেষ করার আগে, এবং তারা backup খুঁজে পেয়েছে যা কোনো ডেটাবেস ছাড়াই সাফল্য রিপোর্ট করেছে, একটি storefront প্রতিটি সুরক্ষার বাইরে শোনা, এবং deploys যা পুরানো সংস্করণ সেবা রেখে কোড আপডেট করেছে। সব ঠিক করা হয়েছে, প্রতিটি যাচাই দিয়ে যা এখন তাদের ঠিক রাখে। যদি একটি panel-এর বিপণন পৃষ্ঠা এর মতো কোনো তালিকা বহন না করে, তার মানে খুঁজে পাওয়ার কিছু ছিল না।
ফ্রি পরীক্ষা দিয়ে শুরু করুন, তারপর সিদ্ধান্ত নিন
SixPreflight বলে দেয় আপনার হাতে থাকা সার্ভারটি 6amMart-এর জন্য প্রস্তুত কি না, আর ঠিক কী বদলাতে হবে। পুরো কাজটাই বরং আমরা করি চাইলে, আমাদের সাথে কথা বলুন।
প্রতিটি রিলিজে কী বদলেছে দেখুন