لوحة الخادم المصنوعة لوظيفة واحدة — تشغيل 6amMart
تستأجر خادماً جديداً، وتشغل أمراً واحداً، وتسترد صفحة ويب تدير متجرك. يثبت SixPanel خادم الويب وقاعدة البيانات و PHP والذاكرة المؤقتة والعامل في الخلفية والمجدول وخادم websocket و HTTPS — كل شيء مُعدّ بالطريقة التي يحتاجها 6amMart فعلاً.
كل شيء يعمل على خادمك. قاعدة البيانات الخاصة بك، وصورك، وبيانات عملائك.
- أسرع من aaPanel مضبوط تماماً — نفس الأجهزة، نفس المتجر، مقاس
1.76×
أسرع من aaPanel مضبوط تماماً — نفس الأجهزة، نفس المتجر، مقاس
- يعمل متجر كامل
2 نواة / 4 جيجابايت
يعمل متجر كامل
- منشور على CodeCanyon، التثبيت الأول مُنجز لك
مجاني
منشور على CodeCanyon، التثبيت الأول مُنجز لك
- لغات واجهة اللوحة
8
لغات واجهة اللوحة
هل تقرأ هذه الصفحة بمساعدة ذكاء اصطناعي؟
الحصول على SixPanel
يُثبَّت SixPanel بأمر واحد. لا شيء للتسجيل، ولا مفتاح تُدخله، ولا كود تلصقه — إنه الأمر نفسه للجميع. وهو مجاني.
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bashما يحمي أمرًا يعمل بصلاحية root ليس العنوان — بل توقيع الإصدار. يحمل المُثبِّت مفتاح التوقيع الخاص بنا ويرفض تلقائيًا أي ملف لا يطابقه. صفحة التثبيت تشرح ذلك.
جرّبه قبل أن تنزّله
دخول للقراءة فقط
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 دون تكلفة إضافية، ويمكن للوحة أيضًا أن تحدّث نفسها في مكانها. لا خادم تراخيص، ولا مفتاح يُجدَّد.
- الإعداد الأول مجاني — أرسل رمز الشراء وتفاصيل الخادم عبر واتساب أو البريد الإلكتروني.
لا شيء يُفعَّل — يعمل على خادمك أنت، ولا يتصل بنا، ويظل يعمل حتى لو تعطّل هذا الموقع.
ما هي، وما الذي تحل محله
أنت تملك السكريبت. ويبقى على أحد أن يدير الخادم.
اشتريت سكريبت 6amMart من CodeCanyon. وهو مجلد ملفات. وقبل أن يستقبل طلبًا واحدًا، على أحد أن يثبّت خادم ويب وقاعدة بيانات وPHP وذاكرة مؤقتة وعاملًا خلفيًا وشهادة HTTPS — ثم يبقي كل ذلك يعمل.
SixPanel هي الجزء الذي يفعل ذلك. تستأجر خادمًا جديدًا، وتشغّل أمرًا واحدًا، فتحصل على لوحة تحكم في المتصفح. ومن تلك اللوحة تربط نطاقك، وتحصل على HTTPS مجانًا، وتثبّت كود 6amMart الخاص بك من git، وتحدّثه، وتأخذ نسخًا احتياطية، وترى ما المعطوب حين ينكسر شيء.
كل شيء يعمل على خادمك. قاعدة بياناتك، وصورك، وبيانات عملائك.
ثلاث طرق لتشغيلها
اللوحة
في المتصفح. وهنا تفعل كل شيء تقريبًا.
أمر sixpanel
على الخادم، لحين تعذّر فتح اللوحة.
المثبِّت
وتشغّله مرة واحدة.
معه مقابل بدونه
كل صف هو المهمة نفسها، منفَّذة بالطريقتين. على اليمين ما يطلبه تشغيل 6amMart منك بدون SixPanel، وعلى اليسار ما يصير إليه معه.
تشغيل السيرفر
بدونه
بناء خادم يدويًا — nginx وPHP-FPM وMariaDB وRedis وcertbot وcron ومشرف عمليات — وإبقاء كل ذلك حيًا
مع SixPanel
أمر تثبيت واحد. systemd هو المشرف — إعادة تشغيل عند التعطل، إعادة تشغيل عند إعادة التمهيد، حدود الذاكرة، دوران السجل وفحص صحة على كل خدمة، معلن في مكان واحد. في وقت تشغيل Docker، يقوم Docker Compose بنفس الوظيفة.
ضبط أحجام قاعدة البيانات وPHP
بدونه
تخمين إعدادات قاعدة البيانات وPHP، أو الدفع لمن يضبطها
مع SixPanel
يقرأ Autotune الجهاز الفعلي ويكتب الأحجام: عمال PHP، مجموعة مخزن مؤقت قاعدة البيانات، ذاكرة الذاكرة المؤقتة، جداول مؤقتة، وسادة الترتيب والانضمام وسجل التراجع. يغطي 1 نواة / 2 جيجابايت إلى 16 نواة / 32 جيجابايت، والمكانان اللذان يحسبان تلك الأرقام يتم فحصهما ضد بعضهما البعض في كل بناء — لأنهما اختلفا مرة واحدة على 66 من 432 قيمة.
نشر تعديل على المتجر
بدونه
الدفع لمطوّر مقابل كل عملية نشر
مع SixPanel
ادفع الكود إلى git، فيتحدّث المتجر. مع سجل نشر وتراجع، والاحتفاظ بآخر 30 عملية نشر.
التأكد أن النسخة الاحتياطية تعمل
بدونه
الأمل في أن النسخة الاحتياطية تعمل
مع SixPanel
النسخ الاحتياطي يعمل وفق جدول وسياسة احتفاظ، ومرة كل أسبوع تُحمّل اللوحة أحدث نسخة في قاعدة بيانات مؤقتة، وتَعُدّ ما بداخلها، ثم تحذفها.
عندما يتوقف المتجر
بدونه
قراءة تتبّع أخطاء لمعرفة سبب توقف المتجر
مع SixPanel
صفحة صحة فيها نحو عشرين فحصًا، لكل منها جملة واحدة واضحة عن العاقبة وزر إصلاح واحد بالضبط.
ما يكلّفه
بدونه
بناء تلك المنصّة وصيانتها بنفسك هو التكلفة، سواء دفعتها ساعاتٍ أو فواتير.
مع SixPanel
لا شيء. فـ SixPanel مجاني على CodeCanyon، والتثبيت والإعداد الأول مجاني، وأمر التثبيت هو الأمر العام نفسه للجميع — بلا مفتاح تُدخله وبلا كود تلصقه. والتحديثات تصل عبر CodeCanyon، ويستطيع الپانل أيضًا تحديث نفسه في مكانه.
ما الذي لا تحل محله
لا تبيعك سكريبت 6amMart.
تشتريه أنت من CodeCanyon، وSixPanel تثبّت الكود الذي تملكه بالفعل.
ليست استضافة مشتركة.
لا حساب cPanel، ولا مواقع أخرى على الجهاز. SixPanel تتوقع الخادم كله.
لا تدير متجرك.
الأسعار والمنتجات والمندوبون والطلبات تعيش في لوحة إدارة 6amMart نفسها.
ليست CDN ولا خدمة حماية من DDoS.
Cloudflare هي طبقة الحافة الحقيقية، والتوثيق يقول ذلك.
طريقتان لتشغيله
لوحة واحدة، بيئتا تشغيل — وإحداهما هي المُوصى بها
كلتاهما المنتج نفسه، باللوحة نفسها والأوامر نفسها والدليل نفسه. الفارق الوحيد هو طريقة تثبيت البرمجيات التي تعمل تحتهما، وهذا الفارق قابل للقياس.
- مُوصى به
SixPanel
يعمل مباشرة على الخادم
nginx و PHP-FPM و MariaDB و Redis مثبّتة من أرشيف التوزيعة الخاص بالإصدار نفسه ويشرف عليها systemd. لا شيء موضوع في حاويات، فكل وصلة هي unix socket وقاعدة البيانات مضبوطة على الجهاز لا على حاوية. وهذه هي الأسرع من الاثنتين، وإليها يتّجه كل العمل الجديد.
أمر التثبيت
curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh | sudo bash- نظام التشغيل
- Ubuntu 26.04 LTS (موصى به) أو Ubuntu 24.04 LTS أو Debian 13
- PHP
- 8.5 على Ubuntu 26.04، و8.4 على Debian 13، و8.3 على Ubuntu 24.04 — دائمًا حزمة الإصدار نفسه
- قاعدة البيانات
- MariaDB 11.8 على Ubuntu 26.04 وDebian 13، و10.11 على Ubuntu 24.04 — من الأرشيف نفسه
- يشرف عليه
- 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 13 — وDebian 12 الذي يُثبَّت عليه لكنه غير موصى به
- 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 فيُصان ولا يُوسَّع. إن كنت تثبّت اليوم ولديك حرية اختيار نظام التشغيل، فاختر المباشرة.
مقاس، وليس مطالب به
ثلاثة خوادم ، نفس المتجر ، فرق واحد
كل رقم أداء على هذه الصفحة يأتي من جولة واحدة من القياسات على أجهزة حقيقية.
1.76×
السرعة
1.76× أسرع
الإعداد
- ثلاثة خوادم
- AMD EPYC 7713 ، 2 vCPU ، 4 GB ، Ubuntu 24.04 — متطابقة إلا للوحة
- التطبيق نفسه
- 6amMart v4.1 ، نفس البيانات ، نفس الطلبات
- ثلاثة نهج
- بناء يدوي ، aaPanel ، SixPanel
- البحث عن 6 endpoints
- استعلامات قاعدة البيانات المختلفة ، بدون كتابة
- الحمل
- 1 ، 5 ، 10 ، 50 طلب في الثانية
الجدول — SixPanel vs aaPanel vs يدويًا
ms
| نقطة النهاية | SixPanel | SixPanel Docker | aaPanel ، stock | aaPanel ، مضبوطة |
|---|---|---|---|---|
/api/v1/categoriesمجبور على PHP على جميع الثلاثة — الأنظف صف متشابه | 29.146.9 | 34.570.9 | 52.0103.6 | 56.199.9 |
/api/v1/stores/get-stores/allعدد الفهارس والقيود | 17.933.3 | 24.545.0 | 37.876.4 | 38.084.2 |
/api/v1/items/searchالبحث عن المطاعم برمز بريدي | 18.035.9 | 25.143.2 | 44.368.3 | 40.971.1 |
/api/v1/items/popularينضم عبر الكتالوج بأكمله | 41.677.2 | 50.794.6 | 58.4112.1 | 65.3122.9 |
/api/v1/customer/order/listوقع في وغير قابل للتخزين المؤقت — أبطأ استدعاء على كل صندوق | 102.1191.8 | 123.3242.3 | 139.6245.8 | 152.7288.9 |
/ (admin entry)SixPanel تعيد التوجيه في 430 بايت؛ aaPanel عرض 352 KBلماذا ليس مقارنة عادلة 1:1 | 59.6102.7 | 63.5156.3 | 76.7144.5 | 84.8171.2 |
storefront homeتحميل الصور وعرضهالماذا ليس مقارنة عادلة 1:1 | 54.3104.0 | 111.4213.5 | 83.0— | —— |
websocket handshakeاتصالات Reverb للشخصيات الحية | 2.35.8 | 4.211.6 | 2.66.3 | —— |
الأسرع ضد أفضل منافس مضبوط
open_basedir على SixPanel وليس على aaPanel. لو لم نطبقه ، كان سيكون 1.15× أسرع.
كيف تم ضبط كلاهما
aaPanel مضبوطة قبل الاختبار. SixPanel مع ضبط ديناميكي. كلاهما مع نفس البيانات والنقاط والطلبات.
- نفس الأجهزة: 2 نواة ، 4 GB
- نفس نسخة 6amMart: v4.1
- نفس البيانات: متجر حقيقي
- نفس الطلبات: 6 endpoints
- كلاهما مع أفضل ضبط
الاختبار عادل
النتيجة
قاعدة البيانات
من أين يأتي الفارق
يتم فك 1.76× / 1.82× إلى أجزاء
| التكوين | طلب واحد | أربعة في الوقت ذاته |
|---|---|---|
| حسب الطريقة التي يشحنها الاثنان | 1.99× | 1.91× |
| بعد إيقاف تقييد الدليل aaPanel | 1.32× | 1.29× |
| بعد تصحيح وضع مترجمها JIT أيضًا | ≈1.25× | ≈1.21× |
تقسيم الفارق
- تقييد دليل PHP60%
- وضع مترجم JIT الخاطئ8%
- إصدار PHP0%
- لا يزال غير مشروح32%
وهذا بدون إزالة التقييد الأمني. نحافظ على open_basedir لأسباب الأمان.
شكل البيانات
6 endpoints: بحث ، الكتالوج ، الطلب ، التفاصيل ، التحديث ، الحالة. كل منها تقرأ من قاعدة البيانات.
التفاصيل الكاملة
القيد يبطئ البحثالبحث في الملفات
open_basedir: / (بلا حد) — 80ms للبحث
open_basedir: /var/www/html (مقيد) — 45ms للبحث
الفارق: رسم الخريطة الأولية للملفات
aaPanel بدون قيد ينتهي في 80ms ، لذا 45ms + بقية = 1.76×
ننشئ فهرس ملفات عند البدء لتجاوز هذا
لكننا لا نزيل القيد بدلاً من ذلك
| نقطة النهاية | التقييد قيد التشغيل | التقييد مطفأ | التغيير |
|---|---|---|---|
/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 assetبدون قيد | 0.4 | 0.4 | 0% |
60% من الفارق من تقييد أمان PHPتحسينات الأداء
إعداد JIT في PHP رقم من أربع خانات، لا مفتاح تشغيل وإيقاف، والوضعان المسمّيان مختلفان: "function" هو 1205 و"tracing" هو 1254. وسكربت ضبط يتحقق فقط من كون JIT مفعّلاً سيترك الوضع الخطأ في مكانه بارتياح ويُبلغ أن المهمة أُنجزت.
تشحن aaPanel الوضع 1205. وتشحن SixPanel وضع tracing. ثلاثة أزواج متبادلة وضعت tracing في المقدمة على 9 من 9 مسارات عند طلب واحد و9 من 9 عند أربعة في وقت واحد — بمتوسط هندسي 5.1% و6.2%.
أي فرق من هذه بمفرده يقع داخل ضجيج هذه الأجهزة. أما ثمانية عشر من ثمانية عشر تسير في الاتجاه نفسه، فلا.
وبالنسبة إلى 6amMart تحديداً، tracing هو الوضع الصحيح: فوضع function يستهدف الحلقات الرقمية الضيقة، وهي شيء لا ينفّذه طلب Laravel.
JIT بدء التشغيل + ضبط ديناميكيPHP 8.4
يثبّت SixPanel أي إصدار PHP يحمله أرشيف الإصدار نفسه — 8.5 على Ubuntu 26.04، و8.4 على Debian 13، و8.3 على Ubuntu 24.04 — لأن البقاء على حزم التوزيعة نفسها يعني أن التحديثات الأمنية تصل تلقائيًا بلا أي مستودع طرف ثالث في مسار الخدمة. والاعتراض الواضح هو أن PHP الأحدث أسرع.
JIT بدء التشغيل (function = 1205)
opcache مع preload للملفات المشتركة
فالقاعدة التي تُبقي SixPanel على حزم التوزيعة نفسها مجانية — لا تكلّف سرعة. ولا يوجد سقف يجب التحايل عليه أيضًا: فملف composer.json في 6amMart يعلن حدًّا أدنى من 8.5، لكن ذلك إعلان لا قياس، وتشغيل الكود على 8.5.4 أنتج تصدير جدول بيانات متطابقًا بايتًا ببايت وLaravel يعمل، على شجرة CodeCanyon الخالصة وعلى نسختنا المتفرّعة كلتيهما.
أشياء تم تخطيهالم نختبر
اختبرنا مقابل aaPanel فقط ، وليس كل المنتجات. التفاصيل:
- خادم الويب
- تم توقيت كل endpoint عبر السلك وأيضًا داخل عملية PHP واحدة ، على كلا الصناديق.
- قاعدة البيانات
- أوقات الاستعلام فعليًا متطابقة عبر جميع التكوينات الثلاثة.
- كيف يصل PHP إلى قاعدة البيانات
- كلاهما على المقبس المحلي ، تم التحقق من العملية المستقرة بدلاً من ملف التكوين.
- طبقة التخزين المؤقت
- تم عدها بدلاً من القراءة من ملف التكوين: 17.1 أوامر التخزين المؤقت لكل طلب على aaPanel.
- ذاكرة التخزين المؤقت للكود المترجم بـ PHP
- أحداث صفر OOM ، صفر تصادمات التجزئة و صفر إعادة التشغيل اليدوي على كليهما.
- الأجهزة
- متطابقة إلى أسفل نموذج المعالج ومجموعة تخفيفات الأمان المفعلة.
الشيء الأبطأ في 6amMart ليس الخادم ، ولا يمكن لأي لوحة إصلاحهكود التطبيق
تم توقيت 297 صفحة إدارة على مجموعة البيانات الحقيقية 66,701 طلب. 290 منهم الرد في أقل من 300ms.
سبع صفحات تمثل المشكلة برمتها. الأسوأ ، تقرير المعاملات حسب اليوم ، يستغرق 20.86 ثانية.
موجود على كل خادم تم اختباره ولم يتم لمسه بواسطة كل إعداد تم تجربته ، بما في ذلك aaPanel كاملة.
هذا كود 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 ← التطبيق ← النسخ الاحتياطي.
- ضبط تلقائي عند التثبيت، وعند الطلب لاحقًا. يحدد أحجام قاعدة البيانات والذاكرة المؤقتة وعمّال PHP من الجهاز الفعلي.
- يشغّل متجرًا كاملًا على 2 نواة و4 GB.
- تحقق بالقراءة، لا بالتشغيل: أو انقل متجرًا قائمًا إليه. يستطيع SixPanel سحب تثبيت حي من خادم قديم عبر SSH — ملف الإعدادات، والملفات المرفوعة، ونسخة من قاعدة البيانات تُمرَّر عبر الاتصال. لم يُشغَّل في جولة 15 أغسطس، بل جرى التحقق منه بالقراءة فقط. شغّله على خادم احتياطي قبل أن تعتمد عليه، وأبقِ الجهاز القديم إلى أن تفعل.
لماذا يهم: اليوم الأول هو حيث تخسر معظم المتاجر أسبوعًا — وهذا اليوم ينتهي بصفحة تعمل.
نطاقك وHTTPS
شهادات حقيقية، تُجدَّد نيابةً عنك، ومعالجة صحيحة لـCloudflare.
- شهادات Let's Encrypt مجانية، تُجدَّد تلقائيًا عبر مهمة يومية.
- أكثر من نطاق لكل متجر، ولكل وجهة (الإدارة، والمتجر، والـwebsocket)، ولكل منها أعلامها الخاصة للنطاق الأساسي وSSL وCloudflare.
- يراعي Cloudflare. يحاول أولًا الحصول على شهادة Let's Encrypt حقيقية عبر وسيط Cloudflare، وهو ما يعمل مع وضع Full (strict). وإن تعذّر ذلك، يرجع إلى شهادة أصل موقَّعة ذاتيًا لـ10 سنوات، وهي تحتاج وضع Full. ويشحن نطاقات عناوين Cloudflare حتى تُظهر سجلاتك عنوان الزائر الحقيقي لا عنوان Cloudflare.
- رمز Cloudflare واحد، وتدير اللوحة مجموعة من خيارات Cloudflare نيابةً عنك. تعرض المطلوب مقابل الفعلي لكل بند، ومزامنة دفعًا أو سحبًا. وقواعدك الخاصة تبقى بعد الكتابة.
- صفحة جدار ناري تطبع القواعد الدقيقة لخادمك، إضافةً إلى قائمتَي نطاقات Cloudflare والأوامر اللازمة لفحصها. واللوحة لا تمسّ جدار مزوّدك الناري بنفسها.
لماذا يهم: أعطال HTTPS هي القاتل الصامت الكلاسيكي — شهادة تنتهي صلاحيتها يوم سبت تأخذ المتجر معها.
شحن تغييرات الكود
نوعان من التحديث لا يختلطان ببعضهما أبدًا.
- ادفع لتنشر. يبدأ النشر بـwebhook موقَّع من مستضيف git لديك.
- «عمليات النشر ← تحديث» ينقل كود 6amMart الخاص بك. و«الإعدادات ← التحديث الذاتي» ينقل SixPanel. ولا يمسّ أي منهما ملف إعداداتك ولا مجلد data/ ولا قاعدة بياناتك.
- سجل وتراجع، مع الاحتفاظ بآخر 30 عملية نشر.
- حارس شجرة نظيفة. إن كنت قد عدّلت ملفات على الخادم، يرفض التحديث ويسمّي الملفات بدل أن يطمس عملك.
لماذا يهم: أخطر دقائق تشغيل متجر هي تلك التي تلي «النشر» مباشرة — وهذا يجعلها مملة.
ألا تفقد شيئًا
مجدولة وتزايدية ومُثبَتة مرة كل أسبوع بدل افتراض نجاحها.
- نسخ احتياطي تزايدي (restic)، وفق جدول، مع سياسة احتفاظ.
- أربع وجهات: الخادم نفسه، أو S3، أو SFTP، أو Google Drive.
- اختبار استعادة تلقائي أسبوعي إلى قاعدة بيانات مؤقتة — لا تُمسّ بياناتك الحية أبدًا، وتظهر النتيجة في صفحة النسخ الاحتياطي وصفحة الصحة معًا.
- تحتوي النسخة الاحتياطية قاعدة بيانات كل مشروع، والملفات المرفوعة، وملف إعدادات التطبيق. ولا تحتوي كودك — فذلك يعود من git.
- كلمة مرور نسخ احتياطي واحدة مشتركة، تُولَّد مرة وتُحفظ في حالة اللوحة. إن فقدتها فلن تُفتح أي نسخة احتياطية بعد ذلك أبدًا.
- تحقق بالقراءة، لا بالتشغيل: الاستعادة جرى التحقق منها بالقراءة، لا بالتشغيل، في جولة 15 أغسطس. وانظر أيضًا حدَّي الاستعادة أدناه — فهما سبب أهمية هذا.
لماذا يهم: النسخة الاحتياطية التي لم تُفتح أمل، لا نسخة احتياطية. واختبار الاستعادة الأسبوعي هو الفرق.
تشغيلها يوميًا، دون أن تكون مدير أنظمة
اللوحة تسمّي المشكلة وتعطيك الزر.
- صفحة الصحة: نحو 20 فحصًا، مرتبة إلى «يحتاج انتباهًا» و«سليم» و«معلومات»، لكل منها جملة واحدة عن العاقبة وزر إصلاح واحد. وكل فحص محدود بـ2 ثانية والصفحة كلها بـ10 ثوانٍ، فلا يستطيع فحص متعلّق تعليق الصفحة.
- ثلاثة مصادر تختلف على هذا العدد. الدليل المشحون يقول «أكثر من عشرين»، وجرد الكود يحسب نحو 20 فحصًا، ومواصفة صفحة أقدم تقول نحو خمسة عشر. وهذه الصفحة تطبع نحو 20 — الأقل بين الرقمين المستندين إلى المنتج المشحون.
- حارس يعيد تشغيل الخدمات التي تعمل ولكنها لا تعمل. لن يعيد مشرف العملية تشغيل شيء حي وكسر، لأن لا شيء انهار. حلقة SixPanel الخاصة، وفحوصاتها تختبر ما إذا كان العمل يتم بدلاً من ما إذا كانت العملية موجودة.
- محرّك مهام. مهمة طويلة واحدة في كل مرة، وتنتظر البقية في الطابور. ويُبثّ السجل حيًا إلى المتصفح. ويُحتفظ بآخر 20 مهمة، بواقع 2,000 سطر لكل منها.
- محرر لملف إعدادات تطبيقك يحافظ على تعليقاتك وترتيبك وأسطرك غير ذات الصلة، ويمنح كل مفتاح نوع الإدخال المناسب، ويُعلّم المفاتيح التي تملكها الحزمة للقراءة فقط.
- مدير ملفات محصور بمجلدين بالضبط: كود الإدارة وكود المتجر لديك.
- phpMyAdmin عند الطلب — يُشغَّل ويُوقَف من صفحة قاعدة البيانات، ولا يُترك يعمل أبدًا.
- التقاط الاستعلامات البطيئة، تستطيع تشغيله ومسحه من صفحة قاعدة البيانات.
- أمر sixpanel على الخادم، مع صفحة دليل، وورقة مرجعية، وقائمة مرقّمة، ومطابِق «هل تقصد»، وإكمال تلقائي في الطرفية.
- دليل العميل الكامل داخل اللوحة، خلف تسجيل الدخول نفسه — 24 صفحة مهام.
- حزمة دعم بأمر واحد. تجمع الإصدارات، ونتائج الصحة، وحالات الخدمات، واستخدام القرص، وآخر 500 سطر من كل سجل. وقبل كتابتها، يُختصر ملف إعداداتك إلى أسماء المفاتيح فقط، ولا يُجمع ملف حالة اللوحة إطلاقًا، ويُخفى الرمز السري في رابط لوحتك والقيم التي تشبه كلمات المرور.
لماذا يهم: اللوحة التي تفتحها فعلًا كل يوم ينبغي أن تجيب عن «هل كل شيء على ما يرام؟» بنظرة واحدة، لا بساعة كاملة.
إدخال أشخاص آخرين
وصول محدود بالوقت بدل تسليم كلمة مرورك.
- حسابات دخول مؤقتة لمطوّر: باسم وكلمة مرور خاصين به، تنتهي بعد 1 ساعة أو 8 ساعات أو 24 ساعة أو 7 أيام، وحتى 20 حسابًا حيًا في وقت واحد. وتُعرض كلمة المرور مرة واحدة فقط. يستطيعون تشغيل الموقع. ولا يستطيعون تغيير من يدخل، ولا قراءة أسرارك.
- حساب دخول تجريبي للقراءة فقط لعرض اللوحة على شخص ما. جلسات مدتها ساعتان، وكل كتابة مرفوضة، والقيم الحساسة مخفية.
- سجل نشاط، وقائمة بالجلسات الحية تستطيع إلغاءها فرديًا أو دفعةً واحدة.
- تحقق بالقراءة، لا بالتشغيل: سجل النشاط لا يغطي كل شيء. إنشاء مهمة مجدولة وتعديلها وتشغيلها يدويًا كلها تُسجَّل، أما حذف واحدة فلا يكتب أي سجل تدقيق إطلاقًا.
لماذا يهم: معظم اختراقات اللوحات ليست ذكية — إنها كلمة مرور مُخمَّنة على صفحة دخول مرئية. وهذه الصفحة هنا ليست مرئية.
أكثر من متجر على خادم واحد
مفصولة بالبناء، لا بالاتفاق.
- كل مشروع يحصل على مستخدم unix خاص به، وقاعدة بيانات وعلى مستخدم قاعدة بيانات خاص به، وعلى مجلد تطبيق خاص به، وعلى تكوين موقع خاص به ومثيل ذاكرة مؤقتة خاص به على مقبس خاص به — لذا متجر واحد لا يمكنه قراءة أسرار متجر آخر المخزن مؤقتاً، ومسح الذاكرة المؤقتة على واحد لا يمكن أن يفرغ أبداً آخر.
- لا يمكن أن ينتهي مشروعان إلى مشاركة قاعدة بيانات: فالاسم مشتق من معرّف نصي فريد ومُتحقَّق منه.
- خطّط لنحو 2 GB إضافية من الذاكرة و1–2 نواة إضافية لكل متجر إضافي — واحسب 2 نواة، أي أعلى ذلك النطاق، لأن نقص الموارد هو الخطأ المكلف.
لماذا يهم: متجر الوكالة الثاني يجب ألا يستطيع قراءة بيانات المتجر الأول ولو نظريًا — هنا تفرض النواة ذلك، وقد هاجمناه بأنفسنا للتأكد.
سرعة مضبوطة سلفًا
ذاكرة مؤقتة صغيرة جداً لمدة خمس ثوان في خادم الويب على جهازك الخاص، مصنوعة حول أنماط الطلب الخاصة بـ 6amMart.
- ذاكرة مؤقتة لمدة خمس ثوان في nginx على قائمة ثابتة من نقاط نهاية الكتالوج العام. إذا وصلت 100 طلب إلى نقطة نهاية التكوين في نافذة واحدة بمدة خمس ثوان، فإن الذاكرة المؤقتة تحولها إلى بداية PHP واحدة بدلاً من 100 — هذا حساب من نافذة الذاكرة المؤقتة، وليس نتيجة إنتاجية مقاسة. يتم تحديد التخزين بـ 64 جيجابايت، مع إزالة خمولة لمدة 60 ثانية.
- لماذا يهمّ هذا هنا تحديدًا: المتجر يُصيَّر على الخادم، فتصبح كل صفحة يراها المتسوّق عدة استدعاءات للواجهة البرمجية تعود إلى الجهاز نفسه، وكل إقلاع بارد لتطبيق الجوال 15–20 استدعاءً إضافيًا.
- لا تقدّم أبدًا استجابة شخصية أو لمستخدم مسجَّل. أي ترويسة Authorization تتجاوزها. وأي كوكي على الإطلاق يتجاوزها. وnginx يرفض تخزين أي استجابة تحمل Set-Cookie. وقائمة منع منفصلة تغطي الإدارة ولوحة البائع وتسجيل الدخول والدفع والسلة والطلبات واستدعاءات الدفع.
- المنطقة والوحدة واللغة جزء من مفتاح التخزين المؤقت، فلا يمكن أبدًا تقديم متاجر مدينة إلى مدينة أخرى.
- تُبقي المتجر يعمل حين يتوقف PHP. فإن تعلّق تجمّع PHP، يقدّم nginx النسخة القديمة قليلًا ويحدّثها في الخلفية — متجر يعمل بدل جدار من أخطاء 502.
- كل شيء آخر يتبع الأجهزة أيضاً: قاعدة البيانات، ذاكرة تخزين مؤقت الكود المترجم في PHP، ذاكرة الذاكرة المؤقتة وبافرات خادم الويب يتم تحجيمها بواسطة autotune من الجهاز الفعلي.
- طبقات لمعدل الطلبات مضبوطة لشبكات حقيقية. حدود ضيقة على تسجيل الدخول ورموز التحقق وإعادة تعيين كلمة المرور؛ وأوسع للتصفح العادي؛ ومنفصلة للبحث ولكتابات السلة والطلبات. والتوثيق يسمّي هذا باسمه — درع فيضان، لا حماية من DDoS — لأن الحدود لكل عنوان لا يمكن أن تكون دقيقة حين تتشارك مدينة كاملة عنوان IP واحدًا لمشغّل الاتصالات.
- «الحافة» في هذا الموقع تعني Cloudflare، وهي طبقة الحافة الفعلية. وهذه الذاكرة المؤقتة ليست كذلك، ولا تُسمّى كذلك.
لماذا يهم: السرعة هي الشيء الوحيد الذي يشعر به العميل في كل زيارة — وهي سبب نشر هذه الأرقام مع منهجها.
أجزاء اختيارية
شغّلها حين يحتاجها المتجر.
- تتبع الطلبات الحي عبر websockets (Reverb).
- موقع العميل الاختياري بـNext.js، مع تقديم أصوله الثابتة كغير قابلة للتغيير.
- البيع عبر تطبيقات الجوال فقط، بلا موقع، شكل مدعوم.
لماذا يهم: الأدوات التي نادرًا ما تحتاجها يجب ألا تكلّف شيئًا وهي خاملة — هذه تبدأ عند الطلب ثم تنزوي جانبًا.
فحص المتجر (SixPreflight، مشمول)
يفحص الإعدادات داخل متجرك، بخلاف الخادم الذي يعتني به SixPanel.
- SixPreflight مُضمَّنة ومُركَّبة داخل اللوحة كصفحة «فحص المتجر». وتحمل نحو 134 فحصًا، ودرجة موزونة، وتقديرًا بحرف.
- لماذا 134 لا رقمًا أكبر: ثلاثة مصادر داخلية تعطي ثلاث إجابات. العدّ المباشر لمفاتيح الفحص الفريدة في الكود يعطي 163؛ ووثيقة التسليم الهندسية تسجّل 134–136 وتوجّه إلى الأقل بينهما؛ ومواصفة صفحة أقدم تقول نحو 100. وهذه الصفحة تطبع ~134، وهو أدنى رقم يدافع عنه مصدر حالي.
- وحين تعمل داخل SixPanel تغيّر سلوكها عمدًا: تختفي كتل الإعدادات الجاهزة للنسخ واللصق للطبقات التي تملكها اللوحة، وتُحتسب الإعدادات التي تخص لوحة إدارة متجرك بمعزل عن الخادم.
لماذا يهم: قد يكون الخادم مثاليًا بينما إعداد خاطئ داخل المتجر يكلّف طلبات بصمت — وعين ثانية تقرأ تلك الإعدادات.
ما يعمل من تلقاء نفسه
خريطة الأتمتة
«مؤتمت» كلمة يسهل طباعتها. هذه كل مهمة تشغّلها اللوحة من دونك — ما الذي يطلق كلًا منها، وما الذي كنت ستفعله يدويًا في منتصف الليل لولاها.
- مرة واحدة، في البداية
الخادم بأكمله، من أمر واحد
لصقة واحدة على خادم Ubuntu جديد تثبّت خادم الويب وقاعدة البيانات وPHP والذاكرة المؤقتة وعامل الطوابير والمجدوِل وخادم websocket واللوحة نفسها — كل منها بحجم يناسب الجهاز الذي يستقر عليه. تكتب نطاقًا؛ وكل ما عداه يوضع ويُضبط ويُشغَّل.
- قبل كل انتهاء صلاحية
HTTPS يجدّد نفسه
تَصدر الشهادات تلقائيًا — عبر DNS عندما يدير Cloudflare النطاق، فتعمل قبل أن يتمكن الإنترنت أصلًا من الوصول إلى الخادم — وكل تجديد يعيد تحميل خادم الويب عبر خطاف خاص بكل شهادة، فلا يمكن لشهادة معطوبة واحدة أن تجمّد البقية أبدًا.
- وفق جدولك
نسخ احتياطية تعمل فعلًا
نسخ احتياطية تزايدية وفق الجدول الذي تحدده، إلى الخادم نفسه أو S3 أو SFTP أو Google Drive، مع تطبيق سياسة الاحتفاظ بعد كل تشغيل. قاعدة بيانات كل مشروع وملفاته المرفوعة وإعداداته — أما الكود فيعود من git.
- كل أسبوع
اختبار استعادة، لا رسالة نجاح
مرة كل أسبوع تستعيد اللوحة أحدث نسخة احتياطية في قاعدة بيانات مؤقتة تُرمى بعدها، وتَعُدّ الصفوف. النسخة الاحتياطية التي لا يمكن فتحها فعلًا تحوّل صفحة الصحة إلى الأحمر — لأن رسالة النجاح ليست دليلًا.
- كل بضع دقائق
تعافٍ ذاتي للأعطال الصامتة
يعيد الحارس (watchdog) تشغيل الخدمة التي تعمل لكنها معطوبة — الحالة التي يفوّتها المشرف العادي تمامًا، لأن شيئًا لم ينهر. وكل إعادة تشغيل ينفذها تظهر في سجل النشاط مع سببها.
- عند التثبيت والتحديث
ضبط على مقاس الجهاز
تُحسب buffer pool لقاعدة البيانات وذاكرة التخزين المؤقت وأحجام الجداول المؤقتة وعمال PHP من ذاكرة الجهاز وأنويته الفعلية — سلّم أحجام واحد، مُقاس على 36 شكلًا من الخوادم، يطبّقه المثبِّت واللوحة بالطريقة نفسها.
- كل ليلة
صيانة قاعدة البيانات
كنسة ليلية تنظف الصفوف منتهية الصلاحية التي لا يحذفها التطبيق نفسه أبدًا، وفي أيام الأحد تُحسَّن الجداول — فقط عندما تسمح مساحة القرص بذلك، ومع فحص كل نتيجة بدلًا من افتراضها.
- عند كل نشر
فهارس مُقاسة تبقى في مكانها
حزمة من فهارس قاعدة البيانات — قيس كل واحد منها على متجر حقيقي فيه 66,701 طلبًا قبل قبوله — تُفحص وتُعاد بعد كل تغيير في الكود. تُفحص بما يغطيه كل فهرس لا باسمه، فلا يمكن لفهرس أُعيدت تسميته أن يخدعها.
- عند كل git push
من الدفعة إلى النشر، حتى النهاية
ادفع إلى مستودعك فيحدّث المتجر نفسه: سحب، ثم الاعتماديات، ثم ترحيلات قاعدة البيانات، وإعادة بناء ذاكرة الإعدادات المؤقتة فقط حيث ثبت بالقياس أنها آمنة لكودك بالضبط، وإعادة تحميل PHP من دون إسقاط أي طلب. وزر تراجع يحتفظ بالإصدار السابق.
- باستمرار
فحوص صحة تسمّي الحل
أكثر من ثلاثين فحصًا تعمل وفق جداولها الخاصة — الخدمات والقرص والشهادات وDNS وCloudflare وملفات اللوحة نفسها مقابل الإصدار الذي شحنها. والصف الفاشل يسمّي الحل بالضبط، لا المشكلة فقط.
- حين يحتاجك شيء
بريد يحترم صندوق واردك
بريد واحد على الأكثر لكل مشكلة كل ست ساعات، مع حكم ملوّن يُقرأ من معاينة صندوق الوارد — و«تم الحل» بالأخضر عندما تزول المشكلة، فلا يضطر أحد إلى تفسير الصمت.
- عندما تضغط الزر
تحديثات بزر واحد وتوقيع مُتحقَّق منه
زر واحد يجلب الإصدار، ويتحقق من توقيعه مقابل المفتاح المثبَّت على خادمك — فلا يستطيع مضيف تنزيل مُستبدَل أن يعيد تعيين مفاتيح جهازك — ثم يطبّقه ويعيد تشغيل الخدمات بترتيب مدروس بالقياس يُبقي المتجر يخدم زبائنه.
النمط وراء كل هذا: اللوحة تؤدي العمل، وتدوّن ما فعلته، وتفحص نتيجتها بنفسها — وكل ما لا تستطيع التحقق منه، تبلّغ عنه بدل أن تدّعيه.
تحت الغطاء
هندسة متقدمة تعمل من تلقاء نفسها
لا شيء من هذا مجرد خانة في قائمة ميزات. كل عنصر آلية حقيقية بسلوك مُقاس وقواعد أمان صارمة وتقرير يمكنك قراءته.
مشرف ذاتي الإصلاح
حلقة كل 60 ثانية تصلح ما يعطل المتاجر الحية فعلاً: طابور متوقف، شهادة منتهية، وضع صيانة منسي. بقواعد صارمة: لا يشغّل أبداً ما أوقفته أنت، ولا يتصرف أثناء نشر أو نسخ احتياطي.
نسخ احتياطي تزايدي مشفّر
مبني على restic: كل تشغيل يخزن فقط الجديد أو المتغير منذ المرة السابقة، مزال التكرار ومشفّر — فتبقى النسخ اليومية سريعة وصغيرة بينما تُستعاد كل لقطة كاملة. الوجهات: قرص محلي، S3، SFTP، Google Drive.
نسخ مُثبتة، لا مفترضة
نجاح مهمة النسخ ليس دليلاً. تحقق مجدول يفتح أحدث لقطة ويتأكد أن نسخة قاعدة بياناتك موجودة فعلاً بداخلها — الجواب الصادق عن «هل يمكنني الاستعادة؟» يأتي من الملف نفسه لا من رمز الخروج.
مضبوط على خادمك تلقائياً
سلّم قياس واحد مُقاس يحسب ذاكرة قاعدة البيانات وذاكرة Redis وعدد عمال PHP من ذاكرة ومعالج خادمك — عند التثبيت ومجدداً عند تغيير الحجم. المُثبّت واللوحة يتشاركان تعريفاً واحداً تحرسه بوابة بناء.
ذاكرة تخزين مصغّرة مُثبتة الأمان
نقاط API الساخنة تجيب من ذاكرة nginx — من 16.9 ملي ثانية إلى 0.6، بالقياس — لكن لا يدخل إلا ما ثبت أنه مستقل عن الطالب: بوابة ساكنة تقرأ معالجات التطبيق ومسبار حي ثلاثي يؤكد أن عميلاً لن يرى بيانات غيره أبداً.
كل مشروع معزول تماماً
لكل متجر مستخدم unix خاص ومجمع PHP-FPM خاص ونسخة Redis خاصة بكلمة مرور؛ وعماله يعملون داخل sandbox من systemd بنظام للقراءة فقط ودون تصعيد صلاحيات. اختراق مشروع لا يقرأ مشروعاً آخر.
تحديثات موقّعة تشفيرياً
كل إصدار يحمل بياناً موقّعاً بـ ed25519 مع تاريخ انتهاء. ترفض اللوحة أي شيء غير موقّع أو قديم أو موقّع بمفتاح خاطئ — والمفتاح المُبدّل عليه إثبات نفسه أمام الإصدار قبل أن يُوثق به.
يقرأ تطبيقك قبل أن يتصرف
اللوحة لا تفترض شيئاً. تخزين الإعدادات يُقرر بقراءة كود 6amMart الخاص بك، فلا تنكسر بصمت نسخة تقرأ إعداداتها وقت التشغيل. كود CodeCanyon الأصلي والنسخة المحسّنة كلاهما ينال الجواب الصحيح.
إصلاح ذاتي، نسخ تزايدي، تحديثات موقّعة — لا تُعد شيئاً من هذا. هكذا بُنيت اللوحة ببساطة.
لماذا يبدو سهلًا
السهولة قرار تصميم، لا طبقة طلاء
لا شيء من هذا وضع مبسّط يخفي أدوات التحكم الحقيقية. إنها أدوات التحكم الحقيقية نفسها، مرتّبة بحيث تكون الخطوة التالية واضحة دائمًا.
لصقة واحدة، بلا متطلبات مسبقة
لا Docker يجب تعلّمه، ولا ملفات compose، ولا طقوس SSH متوارثة. المكدّس هو حزم Ubuntu نفسها يشرف عليها systemd، وأمر واحد يرسيه بالكامل.
معالج يقترح إجاباته بنفسه
ست خطوات — الأساسيات، كلمة المرور، النطاق، HTTPS، التطبيق، النسخ الاحتياطية. كل خطوة تقترح الإجابة المعقولة؛ فمعظم الإعداد تأكيد، لا اتخاذ قرارات.
اكتب نطاقًا واحدًا، واحصل على الخطة كاملة
من نطاق واحد تخطط اللوحة مضيفات لوحة التحكم وواجهة المتجر وwebsocket، وسجلات DNS المطلوب إنشاؤها، وأيّها ينبغي أن يمرّ عبر وسيط Cloudflare. أما الأسماء التي ستكسر HTTPS بصمت فتُرفض مع الكتابة الصحيحة التي تعمل.
المشاكل تصل ومعها حلّها
لا «فشل» مجرّدة. الصف الأحمر يخبرك بالإعداد أو الملف أو الزر الذي يحلها بالضبط — وهذا هو الفرق بين بند في قائمة مهام ولغز.
كل إجراء مهمة يمكنك مراقبتها
التثبيتات والنشرات والنسخ الاحتياطية والإصلاحات تعمل كمهام بسجلات حية. تعرض الأزرار مؤشر دوران أثناء عملها، والمهمة ترفض الإبلاغ عن النجاح ما لم ينجح فحصها الذاتي المعاد.
الدليل يعيش داخل اللوحة
كل رابط مساعدة يوصلك إلى الصفحة الخاصة بالشيء الذي تنظر إليه. والدليل نفسه يُشحن مع التنزيل ويُنشر على هذا الموقع.
سطر أوامر لليوم السيئ
أمر sixpanel على الخادم يعكس اللوحة — مع صفحة man وإكمال تلقائي في الصدفة — لليوم الذي لا يكون فيه المتصفح خيارًا.
تتحدث لغتك
ثماني لغات. اقدم من هذا الموقع وستفتح اللوحة باللغة التي كنت تقرأ بها؛ واتبع رابطًا في الاتجاه المعاكس فيفعل الموقع الشيء نفسه.
الأشياء الثلاثة التي لا يفعلها غيرنا
ثلاث مطالبات، كل واحدة لها السبب الذي يجعلها حقيقية وليس صفة
لقد قمنا بقياس أنفسنا ضد منافس مضبوط بالكامل، ونشرنا مكان المكسب
يمكن لأي شخص نشر معيار قاموا به. الاختبار الجدير بالتشغيل هو الاختبار حيث يتم إعداد الطرف الآخر بشكل صحيح — لذلك تم ضبط صندوق aaPanel أولاً: ذاكرة تخزين مؤقت الكود المترجم مضاعفة، مجموعة مخزن مؤقت قاعدة البيانات أكبر بـ أربع مرات ونصف، وتم تصحيح العمال من التزام مفرط بـ 50 إلى حجم 14. تم تركها PHP 8.4 ومترجم JIT الخاص به قيد التشغيل عن قصد، لأن هذه هي مزاياه.
لم يقفل الفجوة. 1.65x / 1.80x ضد الصندوق كما يحدث؛ 1.76x / 1.82x ضد الصندوق المضبوط. تحركت قليلاً الطريقة الأخرى.
ثم تم تفكيك الفرق متغير واحد في المرة الواحدة. حوالي 60% منه هو قيد دليل PHP واحد، حوالي 8% هو وضع مترجم JIT الخاطئ، وإصدار PHP يستحق بالضبط لا شيء. حوالي 32% لا يزال غير مفسر، وينشر غير مفسر بدلاً من أن ينسب إلينا.
لماذا يهم هذا: نسبة بدون سبب خلفها هي رقم تسويق. هذا له سبب مقاس لثلثي نفسه واعترافاً للبقية.
قِسنا ثلاثة أنظمة تشغيل، فحصلنا على تعادل، ونشرنا التعادل
ثلاثة خوادم من مزود واحد، مطلوب معاً، متطابق إلا نظام التشغيل. نفس البرنامج، نفس الضبط، نفس البيانات — قاعدة بيانات متجر حقيقي بـ 66,701 طلب. هذه الجولة تطرح نظام التشغيل الذي، وليس وقت التشغيل الذي؛ تم تشغيله على الوقت المسموح به.
فتعادلت. وكان الفارق بين الأجهزة الثلاثة (3.5 %) أصغر من فارق جهاز واحد مع نفسه عبر تشغيلين للإعداد نفسه (8.6 %).
فتقرّرت التوصية بناءً على المدة التي يظل فيها كل نظام يتلقى تحديثات أمنية، لا على السرعة. كما استبعد التقرير أكثر صفوفه إطراءً لأنها كانت مستحيلة حسابيًا.
لماذا يهم هذا: الاستعداد لنشر نتيجة سلبية هو الدليل على أن المنهجية حقيقية. فأي أحد يستطيع نشر قياس فاز فيه.
تخزين مؤقت وحدود مصمَّمة حول أنماط الطلبات الخاصة بـ6amMart
التخزين المؤقت الصغير في nginx متاح لأي أحد. والخاص هنا هو كل ما حوله، ولا يستطيع كتابة أي منه شخص لا يعرف هذا التطبيق:
- قائمة السماح التي تحدد بالضبط أي نقاط النهاية العامة يجوز تخزينها مؤقتًا، مطابَقة على الرابط الخام، مع المنع الافتراضي.
- المنطقة والوحدة واللغة في مفتاح التخزين المؤقت، لأن 6amMart يقدّم متاجر مختلفة لمدن مختلفة من الرابط نفسه.
- خمس قواعد تجاوز تجعل تخزين استجابة شخصية مستحيلًا.
- طبقات لمعدل الطلبات تفصل تسجيل الدخول ورموز التحقق عن التصفح، وعن البحث، وعن كتابات السلة.
- مهل زمنية مثبَّتة عمدًا على بعضها — PHP 120 s، وقراءة nginx 120 s، وإنهاء العامل 130 s — لأن 6amMart يشغّل تصديرات Excel والاستيرادات المجمّعة وتقارير المتاجر الثقيلة داخل طلب الويب بدل الخلفية.
لماذا يهم هذا: كان فيضان بحث بلا مصادقة قادرًا على ملء خادم الذاكرة المؤقتة والبدء بإخراج الجلسات، فيُخرج المتسوّقين المسجَّلين بصمت. وقد كلّف ذلك نحو 278 طلبًا، أي نحو 67 ثانية على اتصال واحد، على جهاز اختبار بذاكرة 8 GB فيه مشروعان. وقد قيس ذلك، وحُدَّ، ثم قيس مجددًا على الجهاز نفسه — وعبر الفيضانات الثلاثة التي يجدولها ملف الأدلة: صفر عمليات إخراج، والجلسة حية في كل مرة.
SixPanel في المقارنة
SixPanel مقارنًا بـaaPanel وCloudPanel وبالبناء اليدوي
هذه مقارنة لمهمة واحدة: تشغيل متجر 6amMart. وليست مقارنة لهذه اللوحات عمومًا، ومن غير الأمانة تقديمها كذلك.
ما لدينا بالضبط عن المنافسَين، مذكورًا بدقة
الجدول يحتوي على 14 صف وعمودي منافسين، لذا 28 خلية منافسة. أربعة من تلك الـ 28 يقولون شيء آخر غير 'لم نختبر هذا'، وإليك كل واحد:
- خلية واحدة تسجل شيء شاهدنا منافساً قيام به. يعيد aaPanel جذر المستند بصمت كلما تم حفظ أي إعداد موقع — مسجل على تثبيت حي. هذا هو صف جذر المستند، عمود aaPanel.
- خليّتان تستندان إلى سلوك طرف ثالث تحقّقنا منه، لا إلى اختبار اللوحتين. فلا أرشيف Ubuntu 26.04 ولا أرشيف Debian 13 يحمل MariaDB 10.11، وكلتا اللوحتين تثبّت قاعدة البيانات من حزم المضيف — فلا تستطيعان على هذين الإصدارين توفير تلك النسخة. أما بيئة التشغيل المباشرة في SixPanel فتأخذ 11.8 من الأرشيف نفسه بدلًا منها، وSixPanel Docker يحمل 10.11 داخل صورته. هذا هو صف MariaDB 10.11، في عمودَي المنافسين كليهما.
- خلية واحدة تقرير قياسنا الخاص لمنافس. تم تثبيت aaPanel على أجهزة متطابقة مع بيانات المتجر نفسه، مضبوط من قبلنا أولاً، ومقاس — هذا هو صف السرعة، عمود aaPanel، والطريقة بأكملها أعلاه. لم يتم قياس CloudPanel، لذا تقول خليتها كذلك.
- جميع 24 خلية منافسة المتبقية تقول 'لم يتم اختبارها من قبلنا'. هذا هو النص الحرفي، في كل واحد منهم — يحسب، وليس يفترض.
لا ندّعي شيئًا عن عمر أي من المنافسَين. فلا مصدر في هذه المجموعة يُثبت عمر أي من المنتجين، فلا تظهر أي دعوى من هذا النوع. وما يستطيع صف «السجل العملي» قوله بصدق هو فقط ما نعرفه عن عمرنا نحن.
قمنا الآن بقياس SixPanel ضد aaPanel — أجهزة متطابقة، بيانات المتجر نفسه، و aaPanel مضبوط قبل الأرقام. الطريقة وكل رقم أعلاه. لم يتم قياس CloudPanel على الإطلاق، ولا يظهر أي مطالبة السرعة عنه في أي مكان على هذه الصفحة.
| لمهمة تشغيل 6amMart | SixPanel | aaPanel | CloudPanel | خادم عادي، يدويًا |
|---|---|---|---|---|
| ما صُمم من أجله | تطبيق واحد فقط — 6amMart | استضافة الويب متعددة الأغراض — لم يتم اختبارها من قبلنا؛ اقرأ قائمة الميزات الخاصة بالبائع | استضافة الويب متعددة الأغراض — لم يتم اختبارها من قبلنا؛ اقرأ قائمة الميزات الخاصة بالبائع | كل ما تبني |
| السرعة، على نفس الأجهزة ونفس المتجر | بالقياس: أسرع 1.76× من aaPanel مضبوط تماماً عند طلب واحد، و1.82× مع أربعة طلبات في وقت واحد، على المسارات التي تصل إلى PHP في كلا الجهازين | المقارنة أعلاه. ثبّتناها وضبطناها وتركنا PHP 8.4 وJIT الخاص بها يعملان | لم يتم اختبارها من قبلنا — ولا نطرح أي ادعاء عن سرعتها | كل ما يحققه مهندسك |
| MariaDB 10.11 على Ubuntu 26.04 / Debian 13 | مع بيئة Docker، نعم — فالصورة مثبّتة على 10.11 مهما كان المضيف. أما بيئة التشغيل المباشرة فتأخذ MariaDB 11.8 من أرشيفَي هذين الإصدارين بدلًا منها، وبالقياس في مواجهة 10.11 على المتجر نفسه فذلك تعادُل. | غير متاح. فلا أرشيف أي من الإصدارين يحمل 10.11، وهذه اللوحة تثبّت من حزم المضيف | غير متاح — نفس السبب | فقط إذا قمت بتشغيل الحاويات بنفسك |
| مواقع أخرى وبريد وDNS وFTP على نفس الجهاز | لا. يرفض برنامج التثبيت أي خادم يعمل عليه بالفعل aaPanel أو CloudPanel أو cPanel أو Plesk، أو يستخدم شيء فيه المنفذين 80/443 | يفوزون هنا. هذا ما هي الألواح العامة — لم يتم اختبارها من قبلنا؛ تحقق من البائع | يفوزون هنا — لم يتم اختبارها من قبلنا؛ تحقق من البائع | ممكن، وكلياً مشكلتك |
| المستخدمون والأدوار والفِرق | لا. حساب مسؤول واحد. بالإضافة إلى تسجيلات دخول مؤقتة وتسجيل دخول تجريبي واحد للقراءة فقط | يفوزون هنا. لم يتم اختبارها من قبلنا؛ تحقق من البائع | يفوزون هنا. لم يتم اختبارها من قبلنا؛ تحقق من البائع | كل ما تقوم بتكوينه |
| مضبوط لهذا التطبيق من الصندوق | يكتب التخصيص الآلي عدد عمال PHP، وحجم مجمّع ذاكرة قاعدة البيانات، وذاكرة التخزين المؤقت، والجداول المؤقتة، والمخزنات المؤقتة، وسجل الإعادة، انطلاقاً من الجهاز الفعلي، من 1 نواة / 2 جيجابايت إلى 16 نواة / 32 جيجابايت — ويُقابَل الموضعان اللذان يحسبانه ببعضهما في كل بناء | لم يتم اختبارها من قبلنا؛ تحقق من البائع | لم يتم اختبارها من قبلنا؛ تحقق من البائع | كل ما تعرفه |
| ذاكرة تخزين مؤقت صغيرة مصمّمة على شكل 6amMart | مدمجة: قائمة سماح، والمنطقة/الوحدة/اللغة داخل المفتاح، و5 حالات تجاوز، وتقديم نسخة قديمة عند تعطّل PHP | تخزين مؤقت nginx صغير متاح في أي مكان — يجب على شخص ما كتابة 6amMart خاص قاعدة التخزين المؤقت | نفس. لم يتم اختبارها من قبلنا | نفس |
| النسخ الاحتياطية | restic، بجدولة، مع سياسة استبقاء، وأربع وجهات، واختبار استعادة تلقائي أسبوعي | لم يتم اختبارها من قبلنا — مقارنة اختبار الاستعادة التلقائي على وجه التحديد | لم يتم اختبارها من قبلنا — نفس | كل ما تقوم بنصه |
| HTTPS مجاني | نعم، مع تجديد تلقائي وإصدار يدرك Cloudflare | لم يتم اختبارها من قبلنا؛ تحقق من البائع | لم يتم اختبارها من قبلنا؛ تحقق من البائع | certbot، بواسطتك |
| عمليات النشر | دفع إلى git؛ سجل ورجوع مع الاحتفاظ بآخر 30 عملية نشر؛ ويرفض الكتابة فوق تعديلاتك | لم يتم اختبارها من قبلنا؛ تحقق من البائع | لم يتم اختبارها من قبلنا؛ تحقق من البائع | كل ما تقوم بنصه |
| جذر المستندات يبقى حيث وضعته | نعم | مسجَّل على تثبيت حقيقي: تُعيد aaPanel جذر المستندات إلى قيمته السابقة بصمت كلما حُفظ أي إعداد للموقع | لم يتم اختبارها من قبلنا | مسؤوليتك أن تضبطه صحيحاً |
| سِجل الخبرة | SixPanel في إصداره الحالي، وهو جديد. لا يمكننا أن نعرض عليك سنوات لم نعشها | لم يتم اختبارها من قبلنا؛ تحقق من المدة التي يشحن فيها البائع منتجه | لم يتم اختبارها من قبلنا؛ تحقق من المدة التي يشحن فيها البائع منتجه | Linux عمره أكثر من 30 عاماً |
| شيفرة مصدرية قابلة للقراءة على خادمك | قد يفوزون هنا. تُشحن الواجهة الخلفية للوحة كـ bytecode من 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 والنواة — ولم يُنتج أي تبديل إصدار فرقًا يستحق النشر. وجهازان متطابقان بايتًا ببايت اختلفا عن بعضهما بنسبة 11.6 % في 20 صفًا من 20، فأرضية الضوضاء أكبر من أي أثر وُجد.
تأخذ بيئة التشغيل المباشرة 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 تأتي من أرشيف المضيف مهما كان ما يعمل داخل الحاوية.
لماذا يشير كل شيء الآن في الاتجاه نفسه
جولة سابقة على محرّكات قواعد البيانات وضعت MariaDB 10.11 في المقدمة، وقد قسّم ذلك التوصية مدةً، لأن Ubuntu 24.04 وحده كان يحمله. وبإعادة القياس على أجهزة متطابقة بالمتجر نفسه ذي 66,701 طلبًا، اختفى ذلك الانقسام.
MariaDB 11.8 في مواجهة 10.11 على التطبيق كاملًا تعادُل. أما الصفوف التي أشارت إلى غير ذلك فقد استُبعدت، لأن أداة القياس كانت تقيس مصافحة مشفّرة لا قاعدة البيانات.
الموضع الوحيد الذي بدا فيه 11.8 أبطأ لا يؤدي أي عمل إطلاقًا.
كان SELECT 1 — عبارة لا تؤدي أي عمل، قرأت 12 ملّي ثانية على أحد الأطراف مقابل 29 و37 ملّي ثانية على الطرفين الآخرين. وأرضية تتغيّر ثلاث مرات ليست تنفيذ استعلام: فـ MariaDB 11.8 يتفاوض على TLS على unix socket و10.11 لا يفعل، فكانت الأداة تقيس مصافحة. وبالقياس المباشر: 24 ملّي ثانية لكل نداء عميل على 11.8، مقابل 6 ملّي ثانية مع تعطيل TLS و10 ملّي ثانية على 10.11. ومتجر لا يدفعها أبدًا — فـ mysqlnd لا يتفاوض على TLS على socket، من 0.12 إلى 0.21 ملّي ثانية لكل اتصال.
الرقم القديم «11.x أبطأ بـ2.7×» لم يكن قط عن 11.8.
جاء من استعلام تقرير واحد على نموذج التكلفة في MariaDB 11.0، وهو مسحوب كادّعاء عن التطبيق كاملًا. فلم يبقَ ما يدعو إلى تثبيت إصدار أقدم: تأخذ بيئة التشغيل المباشرة 11.8 من أرشيفَي Ubuntu 26.04 وDebian 13، و10.11 من أرشيف Ubuntu 24.04.
جواب واحد، وليس جوابًا يتعلق بالسرعة. خُذ الإصدار الذي يظل يتلقّى الترقيعات أطول مدة.
كيف قيس
- قيس في 15 أغسطس 2026، على بناء الحزمة الحالي في ذلك التاريخ. وقد شُحنت إصدارات من SixPanel منذ ذلك الحين، ولم يُعَد تشغيل أي شيء في هذا القسم على الإصدار الحالي. والتاريخ هو ما يثبّت القياس.
- ثلاثة خوادم من المزوّد نفسه، طُلبت معًا، متطابقة إلا في نظام التشغيل — وهي كل إصدار تدعمه بيئة التشغيل المباشرة.
- المعالج نفسه في الثلاثة: 2 × AMD EPYC 7713، 2 نواة. والذاكرة 3,915 / 3,910 / 3,921 MB. والقرص 79 GB لكل منها.
- كانت البرمجيات متطابقة بايتًا ببايت على الثلاثة — MariaDB 10.11، ونفس بناء PHP، ونفس خادم الويب. وقد أُجريت هذه الجولة على بيئة الحاويات، وهو ما جعل ذلك ممكنًا: فهي تُثبّت المجموعة حتى يكون نظام التشغيل هو الشيء الوحيد المتغيّر.
- بيانات حقيقية، لا بيانات اختبارية. قاعدة بيانات متجر إنتاجي حقيقي: نسخة بحجم 410 MB تُستعاد إلى 515 MB، و66,701 طلب، إضافةً إلى 894 MB من الملفات المرفوعة الحقيقية.
- تثبيت SixPanel جديد على كل جهاز، عبر مسار العميل العادي. بلا أي ضبط يدوي — فالضبط التلقائي اختار كل قيمة، واختار القيم نفسها في الثلاثة.
- تسخين، ثم قياس. عيّنات التسخين أُهملت؛ والتشغيل الثاني هو المُبلَّغ عنه.
- مئينات، لا متوسطات.
الطلبات في الثانية — نقطة نهاية البحث، 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 وحده مبتور أصلًا. وقد تُرك العمود كما يطبعه المصدر حتى يمكن وضع الملفين جنبًا إلى جنب؛ أما النسب فهي من هذه الصفحة، وهي الأرقام التي تُقتبس.
اقرأ الكتلة كلها هكذا: «نحو 53 طلبًا في الثانية على 2 نواة، على نقطة نهاية البحث، عند 20 مستخدمًا متزامنًا، على مدى 30 ثانية» — ولا شيء أكثر. وكل واحد من تلك الشروط يرافق الرقم أينما تكرر في هذه الصفحة.
زمن الاستجابة في الخمول — مسجَّل، وغير مطبوع عمدًا
قيس زمن الاستجابة التسلسلي على كل مسار: الصفحة الرئيسية للمتجر، وتسجيل دخول الإدارة، ونقاط نهاية الواجهة البرمجية، بطلب واحد في كل مرة على جهاز خامل.
وتلك الأرقام التفصيلية ليست في هذه الصفحة، وهذا هو السبب. التقرير الداخلي يمنع أي رقم «أسرع بنسبة X %» مأخوذ من تلك الجداول. وجدول من ثلاثة أعمدة بقيم بالميلي ثانية هو ذلك الرقم ناقص عملية طرح واحدة: فأي قارئ معه آلة حاسبة، وكل مُلخِّص ذكاء اصطناعي بلا آلة حاسبة، سينتج المقارنة التي يستبعدها التقرير. وطباعة الجدول مع إضافة «لكن لا تقارن هذه» لا تنفع، لأن الاقتباس يبقي الأرقام ويُسقط التحفظ.
- تعادلت الأجهزة الثلاثة على الرقم المهم، واختلف جهاز واحد مع نفسه أكثر مما اختلفت الثلاثة فيما بينها.
- ظهر فرق صغير ومتسق على زمن الاستجابة التسلسلي في وضع الخمول لأحد المسارات. وهو مسجَّل في التقرير الداخلي وغير مُدَّعى عمدًا، لثلاثة أسباب مذكورة فيه: إنه تكلفة شبه ثابتة لا متناسبة، وهو توقيع انتظار لا عمل؛ ويختفي تمامًا تحت الحمل، وهو تحديدًا حيث كان سيهمّ؛ ومع جهاز واحد لكل نظام تشغيل، لا يمكن فصل إصدار النواة عن ذلك المضيف الفيزيائي بعينه.
- أما صفوف المئينات تحت الحمل لمسارين فقد استُبعدت بالكامل.
استُبعدت صفوف، ويهم أنها استُبعدت
مئينات مسار Ubuntu 26.04 تحت الحمل مستحيلة حسابيًا. فعشرون عاملًا لمدة 30 ثانية تساوي 600 ثانية-عامل، فيكون المتوسط الحسابي لـ1,616 طلبًا مُنجزًا 371 ms. وقد أبلغ ذلك المسار عن p50 وp99 معًا دون ذلك المتوسط — أي p99 أسرع من الطلب المتوسط. وتشغيلاه كلاهما يُظهران ذلك، فهو منهجي في ذلك الجهاز لا عيّنة شاردة.
لو أُخذت تلك الصفوف على ظاهرها لبدا ذلك الجهاز أفضل بكثير تحت الحمل. وهو ليس كذلك — فعدد طلباته المُنجزة يقع ضمن 3.5 % من البقية. وقيمتا المئينين نفسهما غير مطبوعتين في هذه الصفحة: فالتقرير الداخلي يستبعد أرقام زمن استجابة Ubuntu 26.04 تحت الحمل كصنف كامل. والحساب أعلاه يكفي لبيان سبب استبعادها، والاستبعاد هو المقصود.
أداة الاختبار تحمل الآن فحصًا متقاطعًا مبنيًا على قانون ليتل، فتُعلن العيّنة الفاسدة عن نفسها بدل أن تصبح عنوانًا.
قاعدة البيانات، على مجموعة البيانات الحقيقية بحجم 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 % |
الصف الأخير هو النتيجة: قاعدة بيانات بحجم 515 MB داخل تجمّع ذاكرة بحجم 1,024 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، ثم دعم المجتمع طويل الأمد | نحو 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 يشغّل حزمة 6amMart كاملة على Ubuntu 26.04 وUbuntu 24.04 وDebian 13 — الثلاثة التي قِيست — وقد تحقق ذلك على بيانات إنتاج حقيقية.
- كل إصدار مدعوم يحمل في أرشيفه قاعدة بيانات تعمل — MariaDB 11.8 على Ubuntu 26.04 وDebian 13، و10.11 على Ubuntu 24.04 — وبالقياس على المتجر نفسه، 11.8 في مواجهة 10.11 تعادُل. وبيئة الحاويات تثبّت 10.11 في صورتها إن أردت تلك النسخة تحديدًا.
- Ubuntu 26.04 LTS موصى به، ويتلقى تحديثات أمنية حتى أبريل 2031.
- خادم بـ2 نواة / 4 GB خدّم نحو 53 طلبًا في الثانية على نقطة نهاية البحث، عند 20 مستخدمًا متزامنًا، على مدى 30 ثانية، على كتالوج بحجم حقيقي فيه 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. فبيئة التشغيل المباشرة ترفضه بالاسم، ولم يُقَس قط.
ما الذي كسرته الجولة، وأصلحناه
ثلاثة عيوب حقيقية ظهرت فقط لأن القياس جرى على خوادم حقيقية ببيانات حقيقية. وهذه الثلاثة هي كل ما يسجّله المصدر — فالقائمة كاملة، لا منتقاة.
- 1فشل المثبِّت على Debian 13. فالصورة المصغّرة لا تشحن git، فانكسر الاستنساخ تمامًا. أُصلح.
- 2أداة الاختبار لم تكن تقيس شيئًا في صفوف الواجهة البرمجية. فقد كانت ترويسات طلبها تُقسَّم، فطبع كل صف من صفوف الواجهة البرمجية صفر عيّنات — بصمت، على الأجهزة الثلاثة. أُصلح، والتشغيل الذي لا يجمع أي عيّنات صار يقول ذلك بوضوح بدل طباعة نتيجة صامتة.
- 3سكريبتان اختلفا على حد ذاكرة PHP، بينما ادّعى تعليق أن المعادلتين متطابقتان تمامًا. صُحِّح.
هذا القسم يبقى في الصفحة. فهو الدليل على أن القياس كان حقيقيًا.
ما تحتاجه
ما تحتاجه، وما يستغرقه التثبيت الجديد فعلًا
| المتطلب | التفصيل |
|---|---|
| نظام التشغيل | Ubuntu 26.04 (موصى به) أو Ubuntu 24.04 أو Debian 13 — ثلاثة بالضبط. ولا شيء غيرها: فالإصدارات الأقدم، ومنها Debian 12، وكل توزيعة أخرى مرفوضة بالاسم قبل تنزيل أي شيء. وقد انتهى الدعم الأمني المجاني لـ Debian 12 في يوليو 2026؛ وبيئة الحاويات ما زالت تُثبَّت عليه، لكن لا ينبغي أن يبدأ متجر جديد هناك. |
| نوع المعالج | x86_64، أو arm64 (ويُكتب أيضًا aarch64). |
| أنوية المعالج | 2 نواة هي الحجم المريح لمتجر واحد. والضبط التلقائي يدعم من 1 نواة إلى 16 نواة. |
| الذاكرة | 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. ولا شيء غيرها، أبدًا. |
| الوصول | حساب الجذر للخادم. والمثبِّت يرفض العمل بأي حساب آخر. |
| كودك | كود 6amMart الخاص بك في مستودع git خاص. فـSixPanel يثبّت من git، لا من ملف مضغوط. |
| هاتفك | تطبيق مصادقة. فالدخول بخطوتين مطلوب لحساب المالك ولا يمكن إطفاؤه. |
| نطاق | والقدرة على تعديل سجلات DNS الخاصة به. |
| متجر ثانٍ | نحو 2 GB إضافية من الذاكرة و1–2 نواة إضافية لكل متجر إضافي. وخطّط لأعلى ذلك النطاق — 2 نواة — فهو الطرف المتحفظ. |
| ما يكلّفه | لا شيء. فـ SixPanel مجاني ومنشور على CodeCanyon، والتثبيت والإعداد الأول مجاني أيضًا. ولا يوجد سيرفر تراخيص، ولا مفتاح يُجدَّد، ولا كود شراء في أمر التثبيت. |
ما يثبته SixPanel: nginx و PHP-FPM و MariaDB و Redis وخدمة لوحة Node.js، كلها يشرف عليها systemd وكلها من أرشيف التوزيعة الخاص بالإصدار نفسه — PHP 8.5 مع MariaDB 11.8 على Ubuntu 26.04، و8.4 مع 11.8 على Debian 13، و8.3 مع 10.11 على Ubuntu 24.04. وبيئة Docker تثبّت المجموعة نفسها كحاويات، مثبّتة على PHP 8.4 وMariaDB 10.11.
ما يستغرقه التثبيت الجديد فعلًا — الجدول الزمني الصريح
«خمس دقائق» هي أمر التثبيت، لا المهمة. أمر التثبيت نحو خمس دقائق. أما الانتقال من خادم مستأجر إلى متجر حي فنحو ساعة.
| الخطوة | الزمن |
|---|---|
| ضع كودك في مستودع git خاص (مرة واحدة، على جهازك أنت) | نحو 20 دقيقة إن لم تستخدم git من قبل |
| حدّث الخادم وأضف ثلاث أدوات صغيرة | دقيقة أو دقيقتان |
| شغّل أمر التثبيت — يفحص النظام، ويثبّت Docker، ويتحقق من التوقيع، وينزّل الملفات ويفحصها، ويولّد كلمات المرور، ويختار منفذ لوحة عشوائيًا، ويحدد الأحجام كلها للجهاز، ثم يبني ويشغّل | 273–303 ثانية مُقاسة عبر ثلاثة أنظمة تشغيل — نحو خمس دقائق |
| افتح المنافذ الثلاثة في لوحة مزوّد الاستضافة | بضع دقائق |
| أول تسجيل دخول، وإعداد الدخول بخطوتين على هاتفك | بضع دقائق |
| وجّه النطاق واحصل على الشهادة المجانية | أقل من دقيقة بعد انتشار DNS — ابدأ سجل DNS مبكرًا |
| ثبّت كود 6amMart الخاص بك من git | بضع دقائق |
| الإجمالي لأول خادم | خصّص ساعة. وستنتهي على الأرجح أسرع. |
ما يطبعه المثبِّت في النهاية، وما يجب أن تحفظه فورًا: رابط اللوحة كاملًا، واسم المستخدم، وكلمة المرور. وتُعرض كلمة المرور مرة واحدة وتُخزَّن كبصمة فقط — ولا يمكن قراءتها مرة أخرى.
أكثر أسباب الفشل شيوعًا ليس التثبيت. بل عدم فتح منفذ اللوحة عند مزوّد الاستضافة.
الأمان
الأمان — ما يمكن إثباته فقط
كل بند هنا يمكن فحصه في المنتج. ولا شيء هنا ادعاء بسلامة عامة. والثغرات في هذا الجانب مذكورة في قائمة الحدود الصريحة أدناه، لا مخفية.
الوصول إلى اللوحة أصلًا
- اللوحة لا تستجيب إلا تحت عنوان سري. وكل ما عداه يُرجع صفحة «غير موجود» فارغة، فلا يستطيع فاحص المنافذ تمييز اللوحة عن منفذ مغلق. ومنفذ اللوحة نفسه رقم عالٍ عشوائي يُختار عند التثبيت، ويختلف في كل خادم.
- العنوان السري بوابة أمام تسجيل الدخول، لا بديل عنه — فاسم المستخدم وكلمة المرور ورمز الخطوة الثانية كلها تعمل خلفه.
- رمز الدخول الخاطئ يُقارَن بزمن ثابت، ويُجاب بصفحة «غير موجود» الفارغة نفسها، بعد تأخير ثابت قدره 200 ms. ويُحتسب ضمن حظر لكل عنوان. والتأخير محدود بـ32 محاولة خاطئة قيد التنفيذ؛ وبعد ذلك الحد تعود «غير موجود» فورًا. فالرمز الخاطئ يكلّف مثل أي شيء آخر حتى ذلك الحد، لا دائمًا — و20 رمزًا خاطئًا في 15 دقيقة تحظر العنوان 30 دقيقة في الحالتين.
- على تثبيت جديد يُولَّد اسم الدخول — admin مع أربعة أحرف عشوائية، مثل admin7f3q — فلا يجد الروبوت الذي يعثر على صفحة دخول اسمًا يستهدفه. أما التثبيت الذي يحمل بصمة كلمة مرور من قبل فيحتفظ بالاسم العادي admin.
- قفل اختياري لنطاق اللوحة. فحين يُضبط نطاق للوحة، حتى الطلب المباشر إلى عنوان IP الخادم يحصل على «غير موجود» الفارغة نفسها. وطريق العودة عبر SSH.
تسجيل الدخول
- تبصيم كلمات المرور (bcrypt)، وكوكي جلسة موقَّع، ورموز خطوة ثانية لا يمكن إطفاؤها لحساب المالك.
- حظر يصمد بعد إعادة التشغيل: 20 كلمة مرور فاشلة في 15 دقيقة تحظر ذلك العنوان 30 دقيقة. وخمسة رموز خطوة ثانية خاطئة تفعل الشيء نفسه.
- قائمة سماح اختيارية بعناوين IP على نموذج الدخول — وحفظ قائمة لا تتضمن عنوانك مرفوض، فلا تستطيع حبس نفسك خارجًا.
ما ترفض اللوحة فعله
- منع افتراضي على كل مسار، إضافةً إلى فحص للطلبات عبر المواقع على كل تغيير. وwebhook النشر هو الاستثناء الوحيد ويُثبت نفسه بتوقيع على جسم الطلب الخام بدلًا من ذلك. وتُتجاهل التسليمات المكررة والتسليمات الأقدم من خمس دقائق، ويُكتب كل رفض في سجل النشاط.
- لا يستطيع مدير الملفات الوصول إلى المكدس. يتم تسييجه بمجلدين — كود الإدارة والرمز الواجهة الأمامية — مع ملكية منفصلة
- قرارات الثقة تستخدم نظير الشبكة الحقيقي، لا ترويسة يستطيع العميل كتابتها.
- التوجيه الحساس لحالة الأحرف يُضبط قبل أول وسيطة، وهو ما أغلق تجاوزًا حقيقيًا كان يمرّ فيه مسار بحالة أحرف مختلفة من فحص مصادقة حساس لحالة الأحرف.
الأسرار
- ملف حالة اللوحة للمالك فقط (0600) داخل مجلد للمالك فقط. وملف إعدادات الحزمة 0600. ومقبس سطر الأوامر مقبس Unix للمالك فقط — للجذر فقط بحكم صلاحيات الملف، وغير مكشوف على الشبكة أبدًا.
- يتم تجزئة كلمة المرور في بداية التمهيد، ثم حذفها من ملف الإعدادات وإزالتها من بيئة العملية، لذا لا يمكنها قراءة
- كان تثبيت المعالج يترك ملف إعدادات التطبيق قابلًا للقراءة من الجميع، متصلًا بذاكرة مؤقتة غير محمية. وقد أُصلح ذلك — فكل تثبيت وتحديث وتراجع ونقل يعيد الآن تثبيت مفاتيح البنية التحتية ويعيد قفل الملف إلى 0600.
- كلمات مرور SSH المستخدمة في النقل لا تظهر أبدًا في قائمة العمليات. بل تُمرَّر عبر البيئة وتُنظَّف من كل سطر سجل.
- حزمة الدعم تُرشَّح قبل كتابتها — فالإعدادات تُختصر إلى أسماء المفاتيح، ولا يُجمع ملف حالة اللوحة إطلاقًا، ويُخفى رمز الدخول السري والقيم التي تشبه كلمات المرور.
عزل البيانات
- كل مشروع يعمل بمستخدم unix خاص به، مع مجلد تطبيق بصلاحيات 0700 وملف إعدادات بصلاحيات 0600. والحاجز هو نواة النظام وهي ترفض مستخدماً مختلفاً — لا تحقّق داخل PHP يمكن لثغرة في PHP أن تتجاوزه.
- كل مشروع يحصل أيضاً على مستخدم قاعدة بيانات خاص به بصلاحيات محدودة بمخططه وحده، ومجمّع عمال PHP خاص به على socket خاص به، ومثيل ذاكرة تخزين مؤقت خاص به بكلمة مرور خاصة به وسقف ذاكرة خاص به.
- وقد اختُبر هذا بمهاجمته لا بالادعاء. فكل محاولة قراءة عبر المشاريع جُرّبت فعلاً من داخل PHP لأحد المشاريع، على هذه اللوحة وعلى aaPanel. وفشلت كلها على الاثنتين — لكن حيث تتقاطعان يفترق طريقهما: ملف خاص كتبه موقع آخر في المجلد المؤقت المشترك كان قابلاً للقراءة على aaPanel ومرفوضاً هنا.
- و PHP محصور فوق ذلك داخل mount namespace على مستوى النواة. وقد أغلق المجلد المؤقت المشترك (من 57 مدخلاً ظاهراً إلى 0)، وشيفرة اللوحة نفسها، وإعدادات موقع كل مشروع — أي كل نطاق على الجهاز — وقائمة العمليات الظاهرة (من 138 إلى 6). والكلفة المقيسة: لا شيء. 217 عملية بحث في نظام الملفات لكل طلب قبله، و217 بعده.
- واقتراحان آخران رُفضا بالقياس بدل أن يُشحنا: إخفاء إعدادات خادم الويب لم يُغلق شيئاً وعطّل أداة الفحص التي تقرأها، وحجب مجلد اللوحة بالكامل كان سيُسقط معه أداة إدارة قاعدة البيانات.
- ومشكلة الذاكرة المؤقتة المشتركة الواحدة التي حلّ هذا مكانها كانت حقيقية، وهي موصوفة بالكامل في قسم الاختبار أدناه بدل أن تُحجب.
الإصدارات — ومسار التحديث الوحيد غير المُتحقَّق منه
- يتم توقيع نسخ الإصدار، و مفتاح التوقيع متصل بلا إنترنت. تحقق إعدادات اللوحة → التحديث الذاتي التوقيع مقابل مفتاح مثبت على الخادم الخاص بك، ترفض رقم البناء عند أو أسفل المثبت، وتحقق من تجزئة الملف.
- يتم جلب أمر التثبيت والتحقق مقابل بصمة منشورة قبل تشغيله. إذا كان الملف الذي تم تنزيله لا يتطابق، يتوقف الأمر ولا يتم تثبيت أي شيء.
- كل مسار تحديث يتم التحقق من التوقيع الآن — إعدادات اللوحة → التحديث الذاتي، أمر التثبيت، والتحديث الذاتي لسطر الأوامر الخاص به. الثالث يستخدم أن يكون لديه لا يوجد فحص؛ إنه الآن.
- يتم التحقق من برنامج التثبيت نفسه، وليس فقط الإصدار الذي ينطبق. يقرأ خادمك سجل منشور ببصمة برنامج التثبيت، ويتحقق من الملف ضده، ويرفض تشغيل أي شيء لا يتطابق — لذا لا يمكن لمضيف محل أو وسيط يد الخادم الخاص بك برنامج تثبيت معدل.
- يتم اعتماد مفتاح توقيع جديد فقط عندما يكون المفتاح المثبت بالفعل على الخادم الخاص بك قد وقعه — أبداً لأن خدمة التحديث تقول كذلك، وليس أبداً لأن المفتاح الجديد يوقع الإصدار الذي وصل معه. كلا من تلك مضيف مسيس يمكن أن ينتج؛ توقيع المفتاح القديم على المفتاح الذي لم يره من قبل، فإنه لا يستطيع. هذا ما يوقف أي شخص من إعادة تشغيل مفتاح الخادم الخاص بك.
هجوم مُقاس، محدود، وأُعيد قياسه
هذا هو الدليل الأمني في هذه الصفحة، لأن له أرقامًا على الجانبين.
قيس كل هذا على جهاز اختبار بذاكرة 8 GB فيه مشروعان وRedis محدود بـ476 MB. وهو جهاز مختلف عن أجهزة الـ4 GB في جولة أنظمة التشغيل أعلاه — إذ لم تُقس في تلك الجولة سوى أجهزة بذاكرة 4 GB، والعبارتان صحيحتان معًا. وقد أُجريت تشغيلات ما بعد الإصلاح مع فرض ميزانية القوائم عند 64 MB، وهو الإعداد الذي يحصل عليه أصغر جهاز مدعوم، لا 245 MB التي يحصل عليها جهاز 8 GB عادةً.
قبل الإصلاح
| القياس | القيمة |
|---|---|
| سقف ذاكرة Redis على ذلك الجهاز | 476 MB |
| مدخل بحث أصناف واحد بأكبر حجم صفحة (limit=200) | 917,704 بايت |
| النسخ المكتوبة لكل مدخل | 2 — مفتاح حي وتوأم قديم بالحجم الكامل |
| 20 عملية بحث بحرف واحد بحجم الصفحة ذاك | +34.2 MB في 4.8 ثانية — مُقاسة، أي نحو 1.71 MB لكل كلمة |
| الطلبات اللازمة لملء خادم الذاكرة المؤقتة كله | 476 ÷ 1.71 ⇐ نحو 278، أي نحو 67 ثانية على اتصال واحد |
| جلسة المتسوّق المسجَّل | أُخرجت — خرج من حسابه بصمت |
ملاحظة حسابية، لأن هذه الصفحة لا يمكنها أن تتخذ من كشف الأرقام المستحيلة أعلاه فضيلة ثم تطبع جدولًا يفشل في ضربه هو. التقرير الداخلي يذكر كلفة 1.79 MB لكل كلمة ورقم ملء يقارب 279 طلبًا. ولا ينتج أي منهما عن الآخر: 917,704 × 2 = 1,835,408 بايت = 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 | عمليات الإخراج | الجلسة |
|---|---|---|---|---|
| 200 طلب بأكبر حجم صفحة (limit=200) | 0 | 0 | 0 | حية |
| 500 طلب بحجم صفحة 50 صفًا | 206 | 51.5 MB | 0 | حية |
| 2,000 طلب بحجم صفحة 50 صفًا | 207 | 51.8 MB | 0 | حية |
عبر تلك الفيضانات بلغ Redis ككل ذروة 53.6 MB من أصل 476 MB. وذلك الرقم للنسخة كلها، لا لعائلة القوائم: فالجدول أعلاه يحدّ بايتات القوائم عند 51.8 MB، فلا يمكن أن تكون 53.6 MB هي ذاكرة القوائم.
على أصغر جهاز مدعوم تُحدَّد عائلة القوائم بـ64 MB من نسخة Redis بحجم 128 MB. وبنحو 1 KB لكل جلسة، يترك ذلك مساحة بحدود 60,000 متسوّق مسجَّل — وهي مساحة تستوعب أيضًا كل ما يفعله Redis على ذلك الجهاز، فعامِلها كرقم هامش، لا كعدد مقاعد.
ما هي اللوحة، بصراحة
ثلاث حقائق يصرّ عليها توثيق المنتج نفسه.
- لوحة التحكم معادلة للجذر على الجهاز، بالبناء: تثبت الحزم، تكتب تكوين النظام وتعيد تشغيل الخدمات
- عنوان الدخول السري بوابة. وتسجيل الدخول يعمل خلفه، وكل تسجيل دخول يمر بكلمة مرور ورمز خطوة ثانية.
- يوجد حساب مدير واحد بالضبط ولا توجد أدوار. والمشاركة تتم عبر حسابات دخول مؤقتة وحساب تجريبي واحد للقراءة فقط.
كيف اختبرنا
جولتان مستقلتان قالتا 'غير جاهز'. هنا ما وجدوه.
معظم صفحات البرنامج تخبرك ما يفعله المنتج. هذه واحدة أيضا تخبرك ما اختبرناه لم نجده.
- الطرق التي تم ممارستها ، 283 تحميل صفحة عبر خمس أحجام شاشة بألوان فاتحة وداكنة
52
الطرق التي تم ممارستها ، 283 تحميل صفحة عبر خمس أحجام شاشة بألوان فاتحة وداكنة
- مفاتيح نص الواجهة المدقق عليها ، في كل من 7 لغات
2,740
مفاتيح نص الواجهة المدقق عليها ، في كل من 7 لغات
- سير العمل في اللوحة المدفوع عبر النهاية ، على كلا مستخدمات 6amMart
34
سير العمل في اللوحة المدفوع عبر النهاية ، على كلا مستخدمات 6amMart
- الجولات المستقلة التي كان قضاؤها "غير جاهز"
2
الجولات المستقلة التي كان قضاؤها "غير جاهز"
موضوع واحد يعمل عبر كل إيجاد جدي
كل أسوأ عيب كان سطح أخضر على شيء مكسور. صفحة تقول "نجاح" ، رقم إصدار يقول شيئًا ، والتطبيق يعمل بشيء آخر.
ما وجدته الجولات ، وما حدث له
هذه لنا ، كانت خطيرة ، وهي ثابتة. افتح أي واحدة للتفاصيل.
كانت النسخ الاحتياطية تعمل ، تقرير النجاح ، ولم تحتوي على قاعدة بياناتمُصلح
قاعدة استبعاد أداة النسخ الاحتياطي صفّيت المدى الكامل ، لذلك استبعاد الدليل العامل = لا نسخة احتياطية للبيانات.
ست لقطات — واحدة منها معلمة كنسخة احتياطية قاعدة بيانات — احتفظت 10888 ملف ونقاط صفرية للبيانات.
اختفت لأن حد التحقق كان 21 يومًا مقابل جدول أسبوعي. لا يوجد تذكر جودة النسخة الاحتياطية.
ثابت ، وثم ثم الاستعادة ثم أثبتت بدلاً من افتراض: نسخة احتياطية طازجة تحتفظ بقاعدة بيانات حقيقية.
واجهة المتجر الأمامية كانت تستمع على منفذ عام ، خارج كل حمايةمُصلح
كانت مرتبطة بكل واجهة شبكة على منفذ غير مشفر عادي ، تجاوز كل حماية.
الاختبار أيضا أنشأ أن موفر الاستضافة لا يطبق جدار حماية بشكل افتراضي.
ثابت ، تحقق من الإنترنت العام ، والتحقق مرة أخرى بعد إعادة الإقلاع.
النشر ، التراجع والتنشيط حدثت الكود والموقع احتفظ بخدمة الإصدار القديممُصلح
SixPanel يبقي ذاكرة التخزين المؤقت للكود المترجم لـ PHP مثبتة — سرعة مقيسة متعمدة.
لذا نشر سحب كود جديد، تشغيل هجرات قاعدة البيانات، إعادة بناء ذاكرة التخزين المؤقت وإعادة تشغيل العمال بينما كان الموقع
تم عرضه بدلاً من الحجج، من خلال خادم الويب الحقيقي على ملف مخزن مؤقتاً: قبل التعديل قدمت الإصدار
إصلاح على جميع المواقع الأربعة.
متجر واحد يمكن قراءة أسرار الدفع والبريد الإلكتروني لمتجر آخر من ذاكرة التخزين المؤقت المشتركةمُصلح
كان التخزين المؤقت خدمة مشتركة واحدة خلف كلمة مرور واحدة لكل عملية php للمشروع.
الإصلاح هو مثيل تخزين مؤقت واحد لكل مشروع ، على المقبس الخاص به ، في الدليل الخاص به.
ثبت بتحويل الهجوم عليه: المسبار انتقل من النجاح إلى الرفض.
تكلفة مقيسة: 3.2 MB من الذاكرة لكل مشروع.
التحديثات كانت هبوط على القرص دون أن تأخذ تأثير ، ثلاث مرات في جولة واحدةمُصلح
خادم أخذ تحديثًا ، أبلغ عن الإصدار الجديد ، وواصل الخدمة مع الإصدار القديم.
مراجعة كاملة لتلك المسارات الأربعة وجدت حوالي 15 فئة من الدولة التي قد لم تتم إعادة تعيينها.
كانت حالة واحدة غير مرئية في طبقتين في آن واحد: كل خادم على القناة المنشورة يحمل cache.
ثابت ، والآن مفروض بفحص يعمل على كل بناء.
ثم ثبت من النهاية إلى النهاية.
على 6amMart الأصلي من CodeCanyon ، انتهى التثبيت والوحة الإدارية كانت غير متاحةمُصلح
CodeCanyon 6amMart الأصلي يقفل لوحة التحكم الخاصة به خلف خطوة تنشيط رمز الشراء بعد التثبيت.
بقيت غير مرئية لفترة طويلة لأن نسختنا المحسنة من 6amMart لها رمز مزيف مدمج.
يجمع المعالج الآن رمز الشراء ويكمل تنشيط التطبيق الخاص به.
تم إصلاح شيئين ذوي الصلة. واجهة المتجر الآن تثبت من ملف zip بدلاً من git.
التوقيع على التحديث حمى الإصدار لكن ليس المثبت الذي طبقهمُصلح
اثنا عشر حالة معادية تمر الآن ضد الحاوية المنشورة.
المشي الإضافي إلى الوراء وجد شيء يستحق الإعلان بوضوح:
قريب واحد آخر من المأزق من نفس الجولة: أمر شهادة اكتسبت خيار لا يملكه.
أربعة وعشرون مكانًا حيث قالت اللوحة للمالك شيئًا لم يكن صحيحًا تمامًامُصلح
"صحي بشكل عام" على خادم أطلقت عليه نظام التشغيل نفسه متدهور.
الشفاء الذاتي يعامل فحص لم يمكن تشغيله كملاحظة للصحة.
معالج الإعداد غير المكتمل الذي لم يطلب نقطة النهاية الإصدار على الإطلاق.
تم إغلاق 24. اثنان من آخر ستة عيوب محمولة تحولوا إلى عدم كونهم حقيقيين.
كل خادم مثبت يقوم بتشغيل ملفات مملوكة لمستخدم غير موجود على الجهازمُصلح
مستخدم ومجموعة آلة البناء الخاصة تم خبزها في الحاوية — 459 ملف بمعرفات UID و GID التي لا موجودة.
غير قابل للاستغلال كما هو موقوف ، لكنه يعني أن النظام كان ينفذ كود لم يختره.
صحح بالتحديث نفسه: 459 ملف بالمالك الخاطئ أصبح صفر.
ما الذي انتظر
أيضا أكدت الجولات نفسها الأشياء التي كانت من المفترض أن تعمل ، وتلك جميعها فعلت. فيما يلي الأرقام.
- إعادة إقلاع كاملة
- العودة عبر SSH في 79 ثانية ، بدون خدمات فاشلة ، كل خدمة في حالة متطابقة بالبايت.
- قتل اللوحة مباشرة
- العودة في حوالي 4 ثواني.
- تحديث عادي
- رمز الخادم ، رسالة GitHub ، البرنامج الوسيط يسحب ، ينشر ، وأسفل على الجانب.
- قطع الطاقة
- بدون فقدان البيانات. قاعدة البيانات تقبل الإصلاح التلقائي. جميع الخدمات تعود.
لا يزال مفتوح ، والتي قيلت هنا بدلاً من تركها
- عداد قاعدة البيانات واحد يقرأ بشكل سيء على خادم أصلي — الجداول المؤقتة التي يتم كتابتها أو حذفها ببطء.
- منتج الحاوية يحتاج إصدار لحمل إصلاح النسخ الاحتياطية و DNS workitem.
- وظيفة خلفية فاشلة قديمة على خادم الاختبار هي السبب الكامل لفشل فحصه الخاص.
لا شيء من هذا غير عادي بالنسبة لبرنامج الخادم. ما هو غير عادي هو نشره. نحن نقول ما اختبرناه ، وكيفية عمله ، والمشاكل التي وجدناها ، وكيف أصلحناها.
حدود صريحة
حدود صريحة
كل واحدة من هذه صحيحة اليوم.
- 1
يأخذ الخادم كله.
لا مواقع أخرى، ولا لوحة تحكم أخرى، ولا شيء آخر على المنفذين 80 و443.
- 2
حساب مدير واحد. لا أدوار، ولا حسابات فريق.
حسابات الدخول المؤقتة وحساب تجريبي للقراءة فقط هما آليتا المشاركة.
- 3
اللوحة مكافئة للجذر على الجهاز.
أي شخص يمكنه تسجيل الدخول إليه يمكنه تشغيل أي شيء على هذا الخادم. هذا ما هي لوحة خادم. على وقت تشغيل Docker، إعادة تشغيل
- 4
الاستعادة ليست بعدُ زر «انقل إلى أي خادم».
تشغيل النسخ الاحتياطي يغطي كل مشروع، لكن الاستعادة تستهدف حاليًا المشروع الافتراضي. والاستعادة على جهاز مختلف تُبقي كلمات مرور الجهاز القديم ومساراته، ولا يستطيع التطبيق الاتصال حتى تضغط «تحديث». كما أن مهمة الاستعادة لا تُشغّل ترحيلات قاعدة البيانات، فتبقى نسخة أقدم تحت كود أحدث متأخرة عن المخطط. ولكليهما خطوة يدوية تعمل؛ ولا أحد منهما تلقائي اليوم. أما مسار الاستعادة نفسه فقد جرى التحقق منه بالقراءة ولم يُشغَّل في جولة 15 أغسطس.
- 5
التراجع عن الكود لا يلغي ترحيلات قاعدة البيانات.
فإن كان ترحيل قد نُفّذ، فإن التراجع عن الكود يحتاج إلى استعادة نسخة احتياطية.
- 6
اللوحة تلتقط الشهادة المُجدَّدة عند إعادة التشغيل.
فالتجديد اليومي يعيد تحميل nginx؛ واللوحة تقرأ شهادتها مرة واحدة عند الإقلاع.
- 7
نقل متجر من خادم قديم جرى التحقق منه بالقراءة، لا بالتشغيل.
كان ذلك في جولة 15 أغسطس. عامِله كمدعوم، لا كمُثبت على خادم من نوع خادمك.
- 8
يرى حارس الشفاء الذاتي فقط الخدمات التي تعلن عن فحص صحة.
على وقت تشغيل الحاوية حاويات websocket والواجهة الأمامية الاختيارية لا تعلن واحد حتى الآن. بشكل منفصل، و وجدت
- 9
كود اللوحة نفسه غير قابل للقراءة على خادمك.
فواجهتها الخلفية تُشحن كشفرة V8 ثنائية والمصادر القابلة للقراءة تُزال من البناء؛ وملفات المتصفح مصغَّرة ومموَّهة. وهذا ردع، لا حماية — فمن يصمّم على ذلك يستطيع معرفة ما يفعله الكود. أما كود 6amMart الخاص بك وبياناتك فلا يمسّهما هذا.
- 10
التحديث الذاتي في سطر أوامر sixpanel بلا فحص توقيع وبلا فحص بصمة.
في التثبيت المحزَّم ينزّل المثبِّت عبر الشبكة ويشغّله بصلاحيات الجذر، وسطر التقدّم الخاص به يدّعي العكس. أما التحديث الذاتي من إعدادات الپانل وأمر التثبيت فموثّقان؛ وهذا المسار الثالث ليس كذلك. وحتى إصلاحه، حدِّث من الپانل.
- 11
في سجل النشاط ثغرة، وقواعد التحقق الإضافي غير متسقة.
فحذف مهمة مجدولة لا يكتب أي سجل تدقيق، بينما إنشاء واحدة وتعديلها وتشغيلها يدويًا تفعل — فحذف مهمة جذر على مستوى اللوحة لا يترك أثرًا. وبمعزل عن ذلك: المهمة المجدولة على مستوى اللوحة تتطلب منك إعادة إدخال كلمة مرورك، بينما إعادة التشغيل وتحديث نظام التشغيل والتحديث الذاتي للوحة — وكلها بصلاحية الجذر على المضيف — لا تتطلب سوى جلسة صالحة.
- 12
ثلاثة إعدادات في اللوحة إعدادات ميتة.
على وقت تشغيل Docker حد معدل API اللوحة، حد معدل المسار الثقيل وحد حجم التحميل يتم قراءتها بواسطة الكود
- 13
لا Kubernetes.
لا يوجد مشغّل Kubernetes في اللوحة.
- 14
مترجم JIT في PHP قيد التشغيل في وقت تشغيل واحد وإيقافه في الآخر.
يشغل SixPanel تتبع JIT في PHP. ضد الوضع aaPanel يقيسه أسرع على 9 من 9 نقاط نهاية في طلب واحد و
- 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 القائمة، بسعر التثبيت نفسه $300. وحين يشحن مورّد 6amMart إصدارًا جديدًا، تنطبق قاعدة الكتالوج المنشورة دون تغيير: التحديث أو الترقية إلى إصدار سكريبت أحدث بنسبة 50 % من سعر التثبيت. وكل تثبيت يُشحن على أحدث إصدار من 6amMart.
الأسئلة الشائعة
أسئلة يطرحها الناس فعلًا
أربعة عشر سؤال، أجاب عليه بنفس الأرقام كما هو الحال في بقية الصفحة.
ما هو SixPanel؟
لوحة تحكم الخادم لوظيفة واحدة: تشغيل متجر 6amMart على خادمك الخاص. يثبت خادم الويب وقاعدة البيانات و PHP
هل يتضمن 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، مقابل مايو 2029 لـ 24.04 وأغسطس 2028 لـ Debian 13. أما Debian 12 فمرفوض بالاسم في البيئة المباشرة؛ وبيئة الحاويات ما زالت تُثبَّت عليه، لكن دعمه الأمني انتهى في يوليو 2026، فلا تبدأ متجرًا جديدًا هناك.
لماذا تتعلق التوصية بمدة الدعم لا بالسرعة؟
لأن السرعة لم تحسم شيئًا. قِيست ستة محاور على عتاد متطابق — نظام التشغيل وPHP وMariaDB وnginx وRedis والنواة — ولم يُنتج أي تبديل إصدار فرقًا يستحق النشر. وجهازان متطابقان بايتًا ببايت اختلفا عن بعضهما بنسبة 11.6 % في 20 صفًا من 20، وهو أكبر من كل أثر وُجد. أما ما يختلف فعلًا فهو المدة التي يظل فيها كل إصدار يتلقّى ترقيعات أمنية، وانتهاء دعم نظام التشغيل هو الحدث الوحيد الذي يفرض إعادة بناء الخادم كاملًا. ولـ Ubuntu 26.04 LTS أطول مدة متبقية من الثلاثة، حتى أبريل 2031.
ما أصغر خادم أستطيع استخدامه؟
نواتا معالجة و4 GB من الذاكرة تشغّلان متجرًا كاملًا — وهذا هو الحجم الذي قِسنا عليه. والمثبِّت يرفض ما دون نحو 1.2 GB ويحذّر دون 2 GB. ولمتجر ثانٍ أو ثالث، خطّط لنحو 2 GB إضافية من الذاكرة و1–2 نواة إضافية لكل منهما.
ما مدى سرعته؟
قياساً مع aaPanel على أجهزة متطابقة — 2 نواة، 4 جيجابايت، نفس المتجر مع 66,701 طلب — أجابت SixPanel 1.76x
كم يستغرق التثبيت؟
حوالي خمس دقائق، بدون مراقبة، على وقت تشغيل الحاوية — 273 إلى 303 ثانية قياس عبر ثلاثة أنظمة تشغيل. الجهاز
هل أستطيع استضافة مواقعي الأخرى على الخادم نفسه؟
لا. المثبِّت يرفض خادمًا يشغّل بالفعل aaPanel أو CloudPanel أو cPanel أو Plesk، أو فيه شيء يستخدم المنفذين 80 أو 443. فـSixPanel يدير خادم الويب والشهادات وخطة الجدار الناري للجهاز كله، ونظامان يفعلان ذلك على جهاز واحد يكسران بعضهما. أما تشغيل مزيد من متاجر 6amMart على الخادم نفسه فمدعوم.
هل أستطيع منح مطوّري وصولًا دون إعطائه كلمة مروري؟
نعم. أنشئ حساب دخول مؤقتًا باسم وكلمة مرور خاصين به، ينتهي بعد 1 ساعة أو 8 ساعات أو 24 ساعة أو 7 أيام. يستطيع تشغيل الموقع. ولا يستطيع تغيير من يدخل ولا رؤية أسرارك. وهناك أيضًا حساب دخول تجريبي للقراءة فقط لعرض اللوحة على شخص ما.
هل يمسّ تحديث SixPanel بياناتي أو كودي؟
لا. تحديث SixPanel يستبدل كود SixPanel الخاص به. إعداداتك، بيانات — قاعدة البيانات، التحميلات، الشهادات، النسخة المحلية
كيف أعرف أن النسخ الاحتياطي يعمل فعلًا؟
تثبت اللوحة ذلك، والسبب الذي يثبته هو أن هذا حدث مرة واحدة. النسخ الاحتياطية التي تم تشغيلها، أبلغت عن النجاح والاحتواء
هل SixPanel مفتوح المصدر؟
لا. الواجهة الخلفية للوحة تُشحن كشفرة V8 ثنائية مع إزالة المصادر القابلة للقراءة، وملفات المتصفح مصغَّرة. ونسمّي ذلك ردعًا، لا أمانًا — فمن يصمّم على ذلك يستطيع معرفة ما يفعله الكود. أما كود 6amMart الخاص بك وبياناتك فهي لك ولا شيء هنا يحجبها عنك. وإن كان وجود مصدر قابل للقراءة على خادمك شرطًا لديك، فاللوحة المفتوحة عامة الغرض خيار أفضل لك.
ما الفرق بين SixPanel و SixPanel Docker؟
اللوحة نفسها، والأوامر نفسها، والدليل نفسه — لا يختلف إلا كيف تُثبَّت البرمجيات تحتها. يثبّت SixPanel nginx وPHP وMariaDB وRedis مباشرة من أرشيف التوزيعة الخاص بالإصدار نفسه ويترك systemd يشرف عليها. وSixPanel Docker يشغّل المجموعة نفسها كحاويات، مثبّتة على PHP 8.4 وMariaDB 10.11 مهما كان المضيف. والبيئة المباشرة أسرع على كل نقطة نهاية قِيست وتعزل المشاريع عند النواة لا داخل PHP، فهي التوصية، وإليها يتّجه التطوير الجديد. اختر بيئة الحاويات إن أردت المجموعة معزولة في حاويات، أو إن كنت تحتاج MariaDB 10.11 على إصدار لا يحمله أرشيفه.
صفحتك تسرد عيوب المنتج الخاص بك. لماذا؟
لأنه الدليل الوحيد الصادق على أن الاختبار حقيقي. شركتان مستقلتان اختبرتاه ، وجدتا مشاكل ، وأخبرنا الجميع بما وجدتاه.
ابدأ بالفحص المجاني، ثم قرّر
تخبرك SixPreflight إن كان الخادم الذي لديك جاهزًا لـ6amMart، وما الذي عليك تغييره بالضبط. وإن كنت تفضّل أن ندير الأمر كله، فتحدّث إلينا.
اطّلع على ما تغيّر في كل إصدار