من 5 إلى 20 بروفايل Headless: تجربة تشغيل وعزل موثقة

اختبار موثق لتشغيل 5 و 10 و 20 بروفايلًا في بيئة Linux معزولة: نتائج عزل الجلسات، واختبارات الثبات، وحدود القياس والتعميم.

دليل عملي

اختبار موثق لتشغيل 5 و10 و20 بروفايلًا في بيئة Linux معزولة: نتائج عزل الجلسات، واختبارات الثبات، وحدود القياس والتعميم.

تجربة مختبر إيجي تاج — LAB-003 | 13 نوفمبر 2026

عندما يعلن مشروع متصفح متعدد البروفايلات أنه يستطيع تشغيل عدد كبير من البيئات المستقلة، فالسؤال الهندسي الأول ليس عدد النوافذ التي تظهر على الشاشة، بل عدد البروفايلات التي بدأت العمل بالفعل، واستطاعت فتح صفحة اختبار، وكتابة بيانات جلسة، ثم قراءتها من سياقها الصحيح دون أن تختلط بسياق آخر. لهذا أجرينا ثلاث جولات متدرجة لاختبار تشغيل Social Browser في وضع Linux Native Headless على بيئة اختبار معزولة، بأعداد 5 ثم 10 ثم 20 بروفايلًا.

الاختبارات الثلاثة نُفذت في 13 نوفمبر 2026، باستعمال بيئة اختبار مؤقتة وصفحات HTTP محلية لا تتصل بحسابات مستخدمين أو منصات خارجية. سجّل كل تشغيل تقرير JSON مستقلًا، يتضمن حالات الفحص والأخطاء ونتائج الثبات. لم يكن الهدف إنتاج إعلان عن قدرة غير محدودة؛ كان الهدف الإجابة عن سؤال محدد: هل تنجح هذه الأعداد على هذا الجهاز، بهذا الإصدار، وضمن نطاق الاختبار المعلن؟

بيئة التشغيل: لماذا يغيّر السياق معنى النتيجة؟

أُجريت التجربة في بيئة Linux مخصصة للاختبار، بعد التحقق من توافر الموارد الكافية قبل زيادة عدد البروفايلات. يفرض بروتوكول التشغيل فحصًا للموارد قبل الجولة الأكبر، كي لا يؤثر نقص الذاكرة المتاحة في تفسير النتائج. هذا الشرط مهم، لأن تشغيل التجربة على جهاز ممتلئ أصلًا قد يكشف ضغط الجهاز أكثر مما يكشف خصائص محرك المتصفح.

بيئة الاختبار تعمل بإصدار من Social Browser مبني على Electron، ضمن حزمة QA معزولة ومجهزة مسبقًا؛ وهي ليست شهادة بأن كل نسخة إنتاجية مثبتة لدى كل مستخدم ستتصرف بالطريقة نفسها. شغّلنا التطبيق على حساب نظام غير root، محدود الصلاحيات، مع تفعيل Chromium Sandbox. ولم نستخدم DISPLAY أو Xvfb، لأن المقصود التحقق من التشغيل بلا واجهة رسومية فعلية، وليس إخفاء نافذة سطح مكتب تقليدية فقط.

لكل جولة مسار بيانات مؤقت وهوية اختبار منفصلة ومنفذ اتصال محلي مستقل. عند طلب أكثر من عشرة بروفايلات، يستخدم الاختبار هوية Developer مؤقتة داخل مجلد QA، كي لا يخلط حدود اشتراك المستخدم بإمكانات المحرك الفنية. لم نعدل ترخيص مستخدم إنتاجي، ولم ننقل ملفات بروفايلات حقيقية إلى بيئة الفحص.

تصميم التجربة: ثلاث مراحل بدل قفزة واحدة

بدأنا بخمسة بروفايلات للتأكد من أن خط أنابيب الاختبار نفسه يعمل: إنشاء البروفايل، بدء التشغيل، فتح التبويب، الانتقال إلى صفحة HTTP محلية، ثم فحص الكوكيز. بعد نجاح هذه الجولة شغّلنا عشرة بروفايلات في عملية اختبار جديدة، ثم عشرين بروفايلًا في تشغيل ثالث منفصل. لم تكن هناك عشرات من المستخدمين الحقيقيين خلف التجربة؛ كل البيانات والأسماء والصفحات كانت بيانات QA اصطناعية.

في كل جولة يتحقق السكربت من أن التبويب المستهدف أصبح يعرض صفحة الاختبار الحقيقية، وليس مجرد نافذة فارغة أو صفحة about:blank. ثم يكتب قيمة Cookie تخص البروفايل، ويعيد قراءتها من سياقه. وأخيرًا يراقب بقاء البروفايلات النشطة فترة ثبات مدتها ثلاثون ثانية، موزعة على تسع جولات تحقق. بهذه الطريقة لا تُحسب عملية إنشاء ناجحة على أنها دليل كافٍ على تشغيل المتصفح.

المقارنة بين المراحل تُظهر مدى نجاح نفس بروتوكول الاختبار عند زيادة عدد البيئات. لكنها ليست اختبارًا محايدًا لزمن فتح كل صفحة على كل جهاز، ولا قياسًا لضغط مرور آلاف المستخدمين الحقيقيين. لإثبات ذلك نحتاج بروتوكولات منفصلة ببيانات شبكة ومقاييس تحميل واضحة.

نتائج الاختبارات: نجاح الأعداد الثلاثة

أظهرت الجولة الأولى حالة PASS لخمسة بروفايلات، مع نجاح عزل الكوكيز 5 من 5 وعدم وجود أخطاء مسجلة. سجّل تقريرها 38 فحصًا، ونجحت فترة الثبات البالغة 30 ثانية عبر تسع جولات تحقق. وبعدها سجّلت الجولة الثانية PASS لعشرة بروفايلات، مع عزل كوكيز 10 من 10، و 68 فحصًا، وفترة الثبات نفسها دون أخطاء.

في الجولة الثالثة بدأ 20 بروفايلًا وعملت جميعًا وفق معايير الاختبار: 20 من 20 في تشغيل البروفايلات، و 20 من 20 في عزل الكوكيز، و 129 فحصًا، مع نجاح فترة ثبات مدتها ثلاثون ثانية وتسع جولات تحقق دون أخطاء مسجلة. كلمة PASS هنا لا تعني أن كل شيء في المتصفح اجتاز كل الاختبارات؛ معناها أن شروط هذا البروتوكول المحدد تحققت.

تختلف أعداد الفحوص بين الجولات لأن بعضها يتحقق من حالة كل بروفايل على حدة، وبعضها يتعامل مع التشغيل الكلي أو الصحة العامة. لذلك لا ينبغي قراءة عدد 129 فحصًا على أنه 129 ميزة مختلفة، أو مقارنته مباشرة باختبارات أمنية أو جودة غير متجانسة.

ما الذي يعنيه نجاح عزل الكوكيز؟

تستخدم تطبيقات Chromium مفهوم Session و Partition لتحديد نطاق الكوكيز وبعض بيانات التخزين والاتصال. عندما يكون لكل بروفايل سياق مستقل، نتوقع أن يظهر الكوكي المكتوب في أحد البروفايلات داخل السياق نفسه، لا في سياق بروفايل مجاور. في تجربتنا لم نعتمد فقط على وجود ملف لكل بروفايل؛ اختبرنا القراءة والكتابة من تبويب يعمل فعليًا داخل محرك المتصفح.

هذا الاختبار يساعد في اكتشاف أخطاء من نوع ربط تبويب بجلسة خاطئة، أو القراءة من نطاق غير مقصود. لكنه لا يفحص تلقائيًا كل مصادر البصمة الرقمية، أو DNS، أو خصائص GPU، أو إضافات المتصفح، أو مدى استقلال الحسابات لدى المواقع الخارجية. عزل الكوكيز جزء مهم من العزل، لكنه ليس تعريفًا شاملًا للخصوصية أو لإخفاء الهوية.

قراءة نتائج الموارد دون الوقوع في فخ الأرقام

سجلت تقارير المراقبة نحو 52 عملية Electron في نهاية جولة الخمسة بروفايلات، و 92 عملية عند العشرة، و 172 عملية عند العشرين. هذه صفوف عمليات من شجرة تشغيل Electron وليست عدد البروفايلات، لأن كل بروفايل يمكن أن يضم عمليات فرعية متعددة للخدمات والصفحات والعزل.

كما يسجل نظام الاختبار قياسات RSS مجمعة من العمليات، لكن جمع قيم RSS لجميع عمليات Chromium يؤدي إلى عدّ صفحات الذاكرة المشتركة أكثر من مرة. لذلك لا يجوز اعتبار هذا المجموع استهلاكًا فعليًا حصريًا للذاكرة أو تحويله إلى متطلب RAM مضمون. تحليل الموارد على نحو صحيح يحتاج قياسات PSS كاملة أو مراقبة cgroups ومعدل استخدام النظام خلال حمل متكرر. وما جُمع هنا أثناء الثبات كان عينات جزئية، لذا لا ننشر رقمًا تقديريًا باعتباره حقيقة إنتاجية.

ظل السيرفر قادرًا على الاستجابة بعد الاختبارات، لكن استقرار الجهاز لحظة الفحص لا يساوي ضمان الاستقرار بعد أيام من العمل أو عند تشغيل مواقع متعددة ذات محتوى ثقيل. هذه حدود يجب التصريح بها كلما نُشرت نتيجة إيجابية.

لماذا اخترنا Native Headless بدل النافذة المخفية؟

يمكن تشغيل متصفح بواجهة رسومية ثم إخفاء النافذة أو وضعها في شاشة افتراضية، لكن ذلك لا يطابق بالضرورة تشغيل المحرك في وضع Headless أصلي. استخدمنا في هذه التجربة خيار Ozone المخصص للتشغيل بلا شاشة، دون اعتماد على DISPLAY أو Xvfb. هذا التمييز مهم لبيئات الخوادم التي لا تحتوي على جلسة سطح مكتب تفاعلية.

الاختبار يؤكد قدرة نسخة QA المعنية على بدء البروفايلات وفتح صفحات محلية داخل هذا السياق. لكنه لا يغني عن اختبارات إضافية لعرض فيديو أو صوت، أو استخدام إضافات MV3، أو مسارات User Scripts، أو التوافق بين Windows و Linux. لكل مسار اعتمادية مختلفة، وبعضها يحتاج اختبارات وظيفية أو اختبارات استخدام طويلة مستقلة.

كيف يمكن لمطور آخر إعادة الفكرة؟

لتكرار الفكرة داخل مشروع تملكه، ابدأ ببيئة HTTP محلية تخدم صفحة بسيطة تحتوي على معرف تجربة، ثم اجعل برنامج الاختبار ينشئ بروفايلات جديدة في مجلد بيانات مؤقت. لكل بروفايل افتح صفحة جديدة، وتحقق من عنوان URL الفعلي، واكتب Cookie عشوائيًا غير حساس، ثم اقرأه وقارنه بالقيمة المتوقعة. لا تستخدم بيانات حسابات حقيقية أو جلسات عملاء، ولا تختبر خدمات خارجية دون إذن.

قسّم التشغيل إلى مراحل متدرجة، وسجّل حالة كل مرحلة في ملف JSON يتضمن الوقت والبيئة والإصدار وعدد البروفايلات. إذا فشلت مرحلة، لا تستمر في رفع العدد قبل تفسير الفشل. ومن الجيد إدخال فشل مقصود في بيئة الاختبار، مثل توجيه بروفايل إلى صفحة غير متاحة، للتأكد من أن الاختبار يميز بين الفشل والنجاح بدل الاعتماد على استجابة سطحية.

بروتوكولنا يعتمد أيضًا على مجلد تشغيل منفصل لكل جولة، وحساب غير ذي امتيازات مرتفعة، وتفعيل Sandbox، والتخلص من بيانات QA بعد انتهاء الفحص. هذه الاحتياطات تجعل قياس السعة أقل تدخلًا في الأنظمة الحية، وتسهل التحقيق عندما تختلف النتائج بين تشغيلين.

ما الذي نحتاج إلى اختباره بعد العشرين؟

أولًا نحتاج اختبارًا أطول من ثلاثين ثانية، يتضمن ساعات من تشغيل صفحات متغيرة مع حساب معدلات الفشل والتعافي. ثانيًا نحتاج مصفوفة شبكات تتعامل مع بروكسيات متعددة، وفشل الاتصال، وعودة الشبكة، وتبديل الإعداد أثناء وجود طلب نشط. ثالثًا يجب اختبار سلوك الإضافات و User Scripts و MCP على البروفايلات المستقلة، وليس الاكتفاء بصفحات HTTP محلية.

رابعًا نحتاج تحليل ذاكرة أكثر صرامة، بتسجيل PSS أو استخدام cgroups، وزمن فتح البروفايل، ووقت الاستجابة، ومعدل استهلاك المعالج على مدى زمني معلوم. وأخيرًا يجب إعادة الفحوص على أجهزة وأنظمة تشغيل وإصدارات أخرى قبل إصدار تعميمات تتجاوز بيئة بيئة الاختبار المستخدمة في هذه الدراسة.

ومن الأفضل نشر أي فشل جديد بالطريقة نفسها التي نعلن بها عن نجاح الجولات: ما السيناريو، وكيف تكرر، وما الخطأ الذي ظهر، وما التغيير الذي أصلحه؟ الأبحاث الهندسية تتقدم عندما تصبح الأخطاء مفهومة وقابلة للقياس.

الخلاصة: نتيجة موثقة لا وعد بلا حدود

أثبتت الجولات الثلاث أن نسخة اختبار Social Browser شغّلت 5 ثم 10 ثم 20 بروفايلًا في وضع Linux Native Headless على بيئة اختبار معزولة، وأن فحوص عزل الكوكيز المرتبطة بكل مرحلة نجحت، وأن المراقبة القصيرة لم تسجل أخطاء. هذه نتيجة مفيدة لتطوير المنتج وتصميم اختبارات أكبر، لكنها لا تبرر الادعاء بأن عدد البروفايلات غير محدود أو أن الأداء مضمون لكل سيناريو.

يمكن قراءة تجربة سابقة عن عزل الكوكيز والبروكسي عبر أربع طرق اتصال في مختبر إيجي تاج، والاطلاع على بقية التجارب والتحديات من صفحة المختبر. ولمعرفة المزيد عن المنتج نفسه، توجد الواجهة العربية ل ـSocial Browser.

هل تريد الاحتفاظ بالمقال أو إعادة استخدامه؟
مجتمع إيجي تاجعن المجتمع

شارك في تقييم ونقاش المقال

رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.

تفاعل مع المقالاختر التفاعل المناسب، ويمكنك تغيير رأيك لاحقًا.
قيّم جودة المقاللا توجد تقييمات بعد — كن أول من يقيّم.

نقاش القراء

النقاش

جارٍ تحميل التعليقات…

بعد هذه المادة

تابع القراءة

كل مواد مختبر إيجي تاج للتجارب التقنية
من نفس القسم04
  1. 02
  2. 03
  3. 04
اختيار القراء

الأكثر قراءة

الترتيب الكامل
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
يتجدد مع النشر

أحدث المواد

  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
  6. 06