قد ينجح المتصفح في فتح عشرين بروفايلًا خلال ثوانٍ، ثم تظهر مشكلات لم تكن مرئية أثناء الإقلاع، مثل توقف إحدى الجلسات عن الاستجابة أو تداخل بيانات التخزين أو استمرار ارتفاع الذاكرة. لذلك لا يكفي الاعتماد على لقطة شاشة أو رسالة نجاح عند إنشاء البروفايل. هذه الدراسة توثق اختبارًا جديدًا على 20 بروفايلًا في وضع Linux Native Headless امتد لخمس دقائق كاملة، مع إعادة فحص الجلسات وقياس ذاكرة عملية الاختبار بصورة أدق من الجولات السابقة.
أُجريت التجربة داخل بيئة اختبار معزولة، باستخدام صفحات وملفات كوكيز اصطناعية لا تخص مستخدمين حقيقيين. وهي اختبار هندسي لمحرك التشغيل ضمن نسخة مخصصة للفحص، وليست شهادة بأن كل إصدار من Social Browser على كل جهاز يستطيع تشغيل العدد نفسه بالسرعة أو الاستقرار ذاته. الهدف أن تكون النتيجة مفهومة وقابلة لإعادة القياس، وأن يظل الفرق واضحًا بين ما ثبت بالمشاهدة وما نحتاج إلى اختباره لاحقًا.
سؤال البحث: هل يستمر العزل بعد نجاح الإقلاع؟
بدأت التجربة بسؤال محدد: هل تستطيع عشرون جلسة مستقلة الوصول إلى صفحات الاختبار، والاحتفاظ بقيم الكوكيز الخاصة بكل بروفايل، ثم الاستمرار في إتاحة تلك القيم طوال نافذة متابعة تستمر 300 ثانية؟ حددنا النجاح قبل التشغيل بوضوح: تشغيل 20 من 20، والتحقق من العزل 20 من 20، وعدم تسجيل أخطاء خلال دورات المتابعة، والحصول على تقرير نتيجة مكتمل.
اختيار نافذة زمنية محددة ضروري لتفسير النتيجة. نجاح خمس دقائق دليل أقوى من مجرد ظهور عشرين نافذة، لكنه ليس معادلًا لاختبار يمتد ساعات أو أيامًا. المدة هنا تسمح برصد بعض حالات التوقف المتأخر وفقد حالة الجلسة، لكنها لا تغطي بالضرورة تحميل مواقع ثقيلة، أو تغير حالة الشبكة، أو تسرب موارد بطيئًا لا يظهر إلا بعد زمن أطول. من الخطأ تحويل نتيجة قصيرة إلى ضمان دائم.
كيف صُممت بيئة الاختبار دون بيانات حقيقية؟
أنشأ محرك الاختبار بروفايلات مؤقتة معزولة، وربط كل بروفايل بتبويب وصفحة HTTP محلية تحمل علامة تحقق غير حساسة. بعد بدء التشغيل، فحص أن التبويب يفتح الصفحة المطلوبة فعلًا، ثم كتب كوكيز اختبار فريدة للبروفايلات وأعاد قراءتها. بهذه الطريقة لا نعتبر مجرد وجود اسم البروفايل في القائمة دليلًا على أن التصفح يعمل أو أن التخزين منفصل.
استُخدم تشغيل Headless أصلي من دون جلسة سطح مكتب رسومية، مع تفعيل Chromium Sandbox وتشغيل الاختبار بصلاحيات نظام محدودة. الاختبار لا يحتاج إلى حسابات في مواقع عامة ولا إلى بروكسيات خارجية أو بيانات شخصية. وقد استُخدمت هوية اختبار داخل بيئة مؤقتة حتى لا تختلط صلاحيات الحسابات الإنتاجية بنتائج قياس قدرة المحرك الفنية. بعد الجولة، يتم إغلاق العمليات وإزالة بيانات التشغيل المؤقتة.
بروتوكول المتابعة: فحوص متكررة لا رسالة PASS واحدة
بعد فحوص التهيئة التي شملت جاهزية البروفايلات والتبويبات وقراءة الكوكيز، بدأت نافذة الثبات الممتدة. خلال هذه النافذة كانت أداة الاختبار تعود إلى البروفايلات النشطة وتقرأ حالة الصفحة وقيمة الكوكيز في سياقها. إذا اختفت قيمة متوقعة أو ظهرت بيانات بروفايل آخر أو تعذر الوصول إلى أحد التبويبات، يفترض أن تُسجل مشكلة في التقرير بدل أن يُحسب التحقق ناجحًا.
تحتوي الجولة على 129 فحصًا أثناء التهيئة والتحقق، و 82 دورة متابعة خلال 300 ثانية. ينبغي فهم الفرق بين الرقمين: الفحوص تمثل نقاط تحقق متنوعة، أما دورة المتابعة فهي مرور متكرر على الحالات النشطة، وليست 82 تجربة مستقلة تمامًا. كما أن عدد الفحوص وحده لا يعبّر عن جودة التطبيق إذا كانت الفروض ضعيفة؛ الأهم أن تكون شروط النجاح قابلة للإبطال، وأن تحفظ نتيجة كل خطوة وتشرح سبب أي فشل.
النتيجة الفعلية لجولة الخمس دقائق
أكملت النسخة المختبرة تشغيل عشرين بروفايلًا بنجاح، ونجحت قراءة الكوكيز الصحيحة داخل سياق كل بروفايل، بنسبة 20 من 20 في الحالتين. استمرت المراقبة 300 ثانية كاملة، وأتمت 82 دورة متابعة، ولم تُسجل أخطاء في فحوص الثبات. حفظ التشغيل النهائي تقريرًا مكتملًا بحالة PASS وبنتيجة خروج ناجحة، وليس مجرد سطر نجاح ظهر قبل إغلاق البرنامج.
هذه الأرقام تثبت أن شروط التجربة المحددة تحققت على بيئة الاختبار المستخدمة. لكنها لا تقول شيئًا مباشرًا عن سرعة تصفح مواقع الإنترنت، أو زمن إنشاء البروفايل على جهاز مستخدم، أو معدل استهلاك المعالج أثناء العمل الحقيقي، أو نجاح كل الإضافات والسكربتات، أو أداء عشرين صفحة فيديو. كل واحد من هذه الأسئلة يحتاج فرضية وأداة قياس منفصلتين.
ما الفرق بين RSS و PSS في تطبيقات Chromium؟
تعمل تطبيقات Chromium عادةً عبر شجرة عمليات؛ فقد توجد عمليات للواجهة والعرض والشبكة والمهام المساعدة. إذا جمعنا قيم RSS لهذه العمليات ببساطة، قد نحسب صفحات الذاكرة المشتركة أكثر من مرة، لأن RSS يسجل الصفحة المقيمة كاملة لدى كل عملية تستخدمها. ولهذا قد يعطي جمع RSS رقمًا أكبر من البصمة الفيزيائية التي يمكن نسبتها إلى مجموعة العمليات.
أما PSS، أي Proportional Set Size، فيوزع حصة الصفحة المشتركة على العمليات التي تستخدمها، ويمنح العملية نصيبها النسبي. وهو أنسب من جمع RSS الخام عند تحليل مجموعة عمليات تتشارك مكتبات وخرائط ذاكرة كثيرة، لكنه لا يتحول تلقائيًا إلى «ذاكرة البروفايل». فقد تتشارك البروفايلات عمليات وخدمات، كما أن أداة القياس نفسها قد تستخدم ذاكرة. يمكن مراجعة شرح PSS في توثيق نواة Linux.
اعتمدت المراقبة هنا على قراءات PSS للعمليات التي تقع تحت شجرة عملية الاختبار المخصصة، بما فيها عمليات Electron والمشرف وأدوات الاختبار. بهذه الطريقة تحسنت تغطية القياس مقارنة بجولة سابقة لم تستطع قراءة سوى جزء من العمليات. ومع ذلك فإن الرقم يصف شجرة الاختبار ككل؛ لا يجوز تقسيمه ببساطة على عشرين وتسميته متوسط RAM لكل بروفايل، ولا يجوز اعتباره استخدام ذاكرة الجهاز كله.
ماذا أظهرت عينات الذاكرة؟
سُجلت 32 عينة خلال التشغيل، منها 30 عينة بعد بداية تشغيل عدد كبير من العمليات. بلغت تغطية القراءة 100% من العمليات التابعة لشجرة الاختبار المرصودة في كل عينة مكتملة؛ وشملت العينة الأخيرة 263 عملية ضمن تلك الشجرة. ظهرت أعلى قراءة مجمعة في العينات المكتملة عند نحو 4,238 ميبيبايت أثناء مرحلة التهيئة، ثم انتهت المراقبة عند نحو 3,448 ميبيبايت. تشمل هذه القيم أدوات الاختبار نفسها، وليست استهلاك محرك المتصفح وحده.
تراجع القراءة بعد ذروة التهيئة يوحي بأن الزيادة المبكرة لم تستمر بالوتيرة نفسها طوال النافذة، لكنه ليس إثباتًا لعدم وجود تسرب ذاكرة. فقد تظهر التسربات بعد ساعات، وقد تؤثر أوقات جمع الذاكرة وإغلاق الموارد وتغير عدد العمليات في الرسم. التفسير السليم يحتاج منحنيات متكررة عبر سيناريوهات حمل مختلفة ومراقبة ما يحدث بعد إغلاق البروفايلات، لا الاكتفاء بنقطة البداية والنهاية. كذلك لا توجد في هذه التجربة قياسات CPU زمنية صالحة للنشر، ولذلك لا يمكن استخراج ادعاء عن كفاءة المعالج منها.
مقارنة عادلة بين دقيقتين وخمس دقائق
في تجربة منشورة سابقًا، نجحت عشرون جلسة خلال 120 ثانية مع 33 دورة متابعة وعزل كوكيز 20 من 20. الجولة الجديدة تمدد نافذة المتابعة إلى 300 ثانية، وتضم 82 دورة، مع تحسين طريقة مراقبة الذاكرة. هذا توسع في المدة وعمق أدوات القياس، وليس اختبارًا مختلفًا تمامًا لكل وظائف المتصفح. لذلك تستطيع المقارنة أن تدعم ثقة أكبر في استقرار هذه الحالات المحددة خلال فترة أطول، لا أن تثبت قدرة إنتاجية غير محدودة.
ويجب الانتباه إلى أن مجموع PSS في الاختبار الجديد لا يقارن مباشرةً بعينات PSS الجزئية من الاختبار السابق، لأن نطاق العمليات المقاسة مختلف. إذا استخدمنا رقمًا جزئيًا في تجربة ورقمًا يغطي الشجرة في تجربة أخرى، فإن الفرق لا يخبرنا بالضرورة أن التطبيق أصبح أبطأ أو أكثر استهلاكًا للذاكرة. قبل إعلان تحسن أو تراجع، يجب توحيد أداة القياس ونطاق العمليات والحمل الزمني.
كيف يعيد المطور اختبارًا مشابهًا بمسؤولية؟
ابدأ بنسخة اختبار مستقلة عن بيانات العمل، وأنشئ صفحة محلية ذات استجابة معروفة. اختر عدد البروفايلات وقيم كوكيز اصطناعية لكل واحد، ثم اكتب معايير نجاح قابلة للإبطال قبل التشغيل. سجل حالة كل بروفايل بعد الفتح، ثم كرر القراءة خلال فترة محددة، واجعل الفشل يظهر في تقرير واضح حتى لو استمرت بقية البروفايلات في العمل. لا تستخدم أي حسابات حقيقية لمجرد زيادة عدد الجلسات في التجربة.
اجمع مؤشرات الذاكرة على فترات معلومة، وسجل عدد العمليات التي نجحت قراءتها إلى جانب عدد العمليات المتوقع قياسها. أشر إلى ما إذا كان القياس يشمل أداة الاختبار أو بعض الخدمات الخارجية، واحفظ نتائج البداية والذروة والنهاية لا رقمًا واحدًا. أضف اختبارًا يقصد إفساد حالة جلسة واحدة لمعرفة هل يلتقط الفحص المشكلة. وعند انتهاء الاختبار، أوقف العمليات المؤقتة وتأكد من عدم بقائها بعد إغلاق البرنامج.
الخطوة الهندسية التالية وحدود الاستنتاج
لتحويل نتائج خمس دقائق إلى تقييم متانة أكثر جدية، نحتاج جولات أطول بمدة محددة مسبقًا، ومواقع اختبار متنوعة الأحمال، وتغييرات شبكة مضبوطة، ومقاييس زمن فتح الصفحات وزمن الاستجابة، ومراقبة CPU والذاكرة بعد إغلاق الجلسات. كما نحتاج اختبار استعادة البروفايلات بعد إعادة تشغيل التطبيق، وسلوك الجلسة عند فقد البروكسي أو رجوعه، وفحوصًا مستقلة للمسارات التي قد تتجاوز الشبكة العادية مثل WebSocket.
التجربة الحالية ناجحة ضمن نطاقها ولا تتطلب المبالغة في تفسيرها. نجاح التشغيل والعزل لمدة 300 ثانية يعطينا أساسًا موثقًا لإجراء اختبار أكبر، ويتيح للمطور معرفة أين يبدأ البحث التالي. لقراءة الجولة السابقة، راجع دراسة ثبات عشرين بروفايل لمدة دقيقتين، واستكشف مختبر إيجي تاج للتجارب التقنية. وللتعرف على التطبيق، يمكنك زيارة الموقع العربي ل ـSocial Browser.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…