في تطبيقات Chromium، فتح عشرين نافذة لا يعني أنها تعمل، ولا يعني أنها معزولة. السؤال الهندسي الأهم هو ما يحدث بعد الإقلاع: هل يبقى كل بروفايل محصورًا في جلسته، وهل تستمر المنظومة في الاستجابة دون أخطاء؟ توثق هذه الدراسة جولة مستقلة شغّلت 20 بروفايل Headless في بيئة Linux معزولة لمدة 120 ثانية. الغرض ليس إعلان سعة إنتاجية أو قدرة على التحمل، بل توثيق ما ثبت بالتجربة وما لم يثبت، بلغة تصلح للمطور الذي يريد إعادة الاختبار.
سؤال البحث وتحديد النجاح
السؤال الذي حكم الجولة: هل يمكن تشغيل 20 بروفايل Headless في بيئة Linux معزولة لمدة 120 ثانية متصلة، مع نجاح تشغيلها جميعًا، والحفاظ على عزل كوكيز كل بروفايل، وعدم تسجيل أخطاء خلال نافذة المراقبة؟
حُدد النجاح بأربعة شروط قابلة للفحص: تشغيل 20 من 20، وعزل كوكيز 20 من 20، ونجاح 33 دورة متابعة موزعة على 120 ثانية، وعدم وجود أخطاء مسجلة. أضيفت 129 عملية فحص أثناء التهيئة والتحقق. كانت النتيجة النهائية status pass. هذه كلمة مختصرة، لكنها محصورة في هذه الشروط وهذه النافذة؛ ليست شهادة على سلوك النظام في كل الظروف، ولا بديلًا عن اختبار طويل أو قياس موارد كامل.
بنية اختبار البروفايلات العشرين والعزل
نفذت الجولة في بيئة اختبار معزولة على Linux Native Headless، مخصصة لاختبارات تطبيق Social Browser. استُخدم Chromium Sandbox، وحساب اختبار محدود الصلاحيات، وخادم محلي تجريبي. لم تُستخدم بيانات مستخدمين حقيقية، ولم تُفتح مواقع عامة. كانت الصفحات والكوكيز اصطناعية ومحلية، ما يجعل النتائج قابلة للتكرار ولا يخلط بين سلوك التطبيق وسلوك مواقع خارجية.
لكل بروفايل مساحة بيانات مستقلة وكوكي اصطناعي يحمل علامة فريدة. لا يكتفي فحص العزل بعدّ النوافذ؛ يتحقق من أن البروفايل يقرأ علامته الخاصة، ولا يستطيع قراءة علامة بروفايل آخر عبر سياق الصفحة. هذا فحص وظيفي لعزل الجلسات، وليس تدقيقًا أمنيًا شاملًا لنموذج التهديد. وجود Sandbox وحساب محدود الصلاحيات يقلل مساحة الأثر، لكنه لا يحول الاختبار إلى تقييم اختراق.
توزعت 129 عملية فحص على التهيئة والتحقق: جاهزية التشغيل، وهوية البروفايل، وعزل الكوكيز، وحالة النافذة. لا يعني الرقم أن كل فحص يزن الشيء نفسه، ولا يصلح كمؤشر منفرد للجودة. وظيفته أنه يوثق نقاط تحقق متعددة بدل الاكتفاء بملاحظة أن النوافذ مفتوحة.
المقارنة مع الثلاثين ثانية ومعنى 33 دورة
الفرق الظاهر بين الجولتين هو المدة: 30 ثانية سابقًا مقابل 120 ثانية الآن، أي أربعة أضعاف. المدة الأطول لا تضاعف العمل نفسه؛ تمنح الأعطال المؤجلة فرصة الظهور، مثل مؤقتات تتأخر، أو تهيئة كسولة تحدث عند أول استخدام، أو نمو ذاكرة مؤقتة، أو تعارض بين عمليات تعمل على فترات مختلفة. الجولة الأولى تغطي الإقلاع المبكر، والثانية تغطي ما بعده.
33 دورة متابعة خلال 120 ثانية تعني متوسط نحو 3.6 ثانية بين دورة وأخرى. هذا المتوسط وصفي فقط؛ عدد الدورات يعتمد على الفاصل المضبوط، وليس نتيجة تُقارن عبر اختبارات مختلفة. نجاح 33 من 33 يعني أن نقاط المراقبة المتكررة لم ترصد فشلًا، لا أن النظام اجتاز 33 اختبارًا مستقلًا. ولأن الجولتين مستقلتان في الإعداد والمنهج، لا تُستخدم نسب النجاح أو أرقام الذاكرة للمقارنة المباشرة بينهما. الاستنتاج المعتدل: 120 ثانية دليل أقوى قليلًا من 30 ثانية، لكنه يبقى قصيرًا.
سجل النتائج في أرقام واضحة
لا تتضمن الجولة قياس زمن CPU صالحًا للنشر، ولا عدد الصفحات المفتوحة لكل بروفايل. غياب هذين الرقمين ليس فشلًا، لكنه يمنع أي حديث عن كفاءة المعالج أو معدل فتح الصفحات. كذلك فإن صفر أخطاء مسجلة يعني صفر أخطاء في السجلات المتاحة خلال 120 ثانية، وليس صفر عيوب.
معنى PSS ولماذا RSS قد يتكرر
RSS هو مقدار الذاكرة المقيمة في العملية، لكنه يحسب الصفحات المشتركة كاملة داخل كل عملية تشاركها. في شجرة Electron، كثير من مكتبات Chromium وملفات الترميز مشتركة بين عمليات متعددة. جمع RSS عبر العمليات يكرر تلك الصفحات مرة لكل عملية، فيتضخم المجموع ولا يمثل الذاكرة الفيزيائية الفعلية.
يعالج PSS جزءًا من هذا التشويه بتقسيم الصفحات المشتركة بين الجهات المشاركة. لذلك فإن مجموع PSS لعملية ومجموعة عملياتها أقرب إلى البصمة الفيزيائية المنسوبة إليها من مجموع RSS. لكنه ليس إجمالي ذاكرة النظام: تبقى ذاكرة النواة، والصفحات المخزنة، وعمليات أخرى خارج الشجرة. كما أن PSS لحظي؛ يتغير مع الجمع، وتحرير الذاكرة، ونشاط العمليات. لا يجوز تحويله إلى استهلاك البروفايل دون تقسيم واضح وثابت.
حدود عينة PSS الحالية وكيف نقيس قياسًا شاملًا لاحقًا
جمعت الجولة PSS من 89 عملية فرعية فقط من نحو 172 عملية Electron، أي عينة غير مكتملة. بدأت السلسلة الجزئية بقيمة مجمعة 1957 MiB وانتهت عند نحو 1568 MiB بعد 120 ثانية. يمكن ذكر الرقمين كسجل خام، لكن لا يجوز قراءتهما كإجمالي استهلاك الذاكرة، ولا كمتوسط لكل بروفايل، ولا كدليل على عدم وجود تسرب. قد ينخفض المجموع لأن تركيبة العينة تغيرت، أو لأن عمليات انتهت، أو لأن ذاكرة مؤقتة حُررت، أو لأن القياس التقط لحظة مختلفة. غياب مجموعة ثابتة من المعرفات يجعل المقارنة الزمنية غير صالحة.
القياس الشامل يحتاج بروتوكولًا صريحًا: تحديد شجرة العمليات كاملة من الجذر، وتثبيت لقطة المعرفات في كل فترة، وجمع PSS و RSS لكل عملية، وتسجيل عدد العمليات وتركيبتها، وفصل الذاكرة المجهولة عن الملفية، واستخدام عدادات الذاكرة على مستوى مجموعة العمليات في النواة لقياس الذروة. يلزم أيضًا تكرار الجولة عدة مرات والإبلاغ عن الوسيط والمدى، لا عن قيمة واحدة. بعد فترة تسخين محددة، يمكن فحص ميل PSS بدل مقارنة نقطتين. هذه خطة قياس، وليست نتيجة منفذة في هذه الجولة.
ماذا لا تثبته هذه الجولة
لا تثبت هذه الجولة أن النظام يتحمل الضغط، ولا أنه يستمر أيامًا. 120 ثانية نافذة قصيرة. لا تثبت عدم وجود تسرب ذاكرة، ولا الإجمالي الكامل للذاكرة، ولا متوسطًا لكل بروفايل. لا تثبت كفاءة CPU، ولا عدد الصفحات التي يمكن فتحها، ولا سلوك الشبكة في الواقع. لا تثبت أن العزل حاجز أمني مكتمل؛ تثبت فقط أن فحص الكوكيز الوظيفي نجح في هذه الجولة. ولا تثبت السلوك عند أخطاء الشبكة أو انقطاعها؛ تلك سيناريوهات تحتاج تقريرًا مستقلًا ومعايير قبول خاصة، ولا توجد هنا نتيجة معتمدة بشأنها.
كذلك، نجاح الجولة على Linux Native Headless لا ينتقل تلقائيًا إلى أنظمة تشغيل أخرى أو إلى وضع واجهة مرئية. النتيجة محصورة في البيئة والنسخ والإعدادات المستخدمة.
وصف تجربة تعليمية قابلة للتكرار
لإعادة تجربة مشابهة دون كشف بنية داخلية، يكفي هذا التسلسل:
1. جهّز بيئة اختبار معزولة وخادمًا محليًا تجريبيًا، وحسابًا محدود الصلاحيات، ولا تستخدم بيانات حقيقية. 2. أنشئ 20 بروفايل، لكل منها مساحة بيانات مستقلة وكوكي اصطناعي بعلامة فريدة وصفحة محلية ثابتة. 3. شغّل البروفايلات وسجّل جاهزية كل واحد منها، مع توثيق الإصدارات والإعدادات العامة دون عناوين أو مسارات. 4. كرر كل فترة فحصًا يقرأ العلامة الخاصة ويحاول قراءة علامة بروفايل آخر، ثم سجّل النتيجة والزمن. 5. استمر 120 ثانية، واجمع السجلات، وأوقف التشغيل، وأرشف ملخصًا منقّحًا. أعد الجولة أكثر من مرة قبل نشر استنتاج.
المهم في الخطوة الرابعة أن يكون الفحص سلبيًا وإيجابيًا: التأكد من قراءة العلامة الصحيحة، والتأكد من رفض العلامة الخاطئة. الاكتفاء بالنجاح الإيجابي يخفي حالات العزل الناقص. وينبغي تسجيل الفاصل الزمني وعدد الدورات مسبقًا، لأن تغييرهما بعد النتيجة يجعل التقرير أقل مصداقية.
خطة بحث تالية: 10 دقائق و 60 دقيقة وأخطاء الشبكة
الخطوة المنطقية هي تمديد النافذة إلى 10 دقائق ثم 60 دقيقة، مع نفس معايير العزل لكن بقياس ذاكرة كامل ومتكرر. في 10 دقائق يمكن رؤية سلوك ما بعد التسخين بوضوح أكبر، وفي 60 دقيقة يمكن فحص ميل PSS لكل عملية بدل الاعتماد على مجموع لحظي. يلزم تثبيت الحمل: صفحات محلية متطابقة، وفاصل فحص معلن، وعدد دورات متوقع، وسجل أخطاء موحد.
بالتوازي، نحتاج قياس زمن CPU لكل عملية، وعدد الصفحات المفتوحة لكل بروفايل، وتجارب أخطاء شبكة محاكاة مثل الانقطاع المؤقت والاستجابة البطيئة وإعادة الاتصال. لكل سيناريو معيار قبول مستقل، ولا تخلط نتائجه بنتائج هذه الجولة. قبل التنفيذ، يُفضل تسجيل الفرضية ومعيار الفشل، ثم نشر النتائج السلبية كما تُنشر الإيجابية.
خلاصة دقيقة
في جولة مستقلة مدتها 120 ثانية، شغلت البيئة 20 بروفايل Headless من 20، ونجح عزل الكوكيز في 20 حالة، وأنجزت 33 دورة متابعة من 33 دون أخطاء مسجلة، بعد 129 فحصًا للتهيئة والتحقق، فكانت الحالة pass. هذه نتيجة مفيدة لأنها تتجاوز لحظة الإقلاع وتكرر الفحص، لكنها تبقى دليلًا قصير الأمد. أما PSS فجُمع من عينة جزئية (89 من نحو 172) بقيم 1957 ثم نحو 1568 MiB، ولا تصلح هذه العينة لإجمالي الاستهلاك أو المتوسط أو نفي التسرب. الخطوة التالية قياس شامل ومدد أطول وسيناريوهات شبكة منفصلة.
لمن يريد السياق السابق، يمكن قراءة الدراسة المرتبطة عن تشغيل 5 و 10 و 20 بروفايلًا لمدة 30 ثانية هنا: دراسة العزل السابقة. ويمكن متابعة منهجية المختبر من صفحة مختبر إيجي تاج للتجارب التقنية، ومعرفة المزيد عن التطبيق من الموقع العربي الرسمي.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…