الرئيسية
» مكتب MS
»
Collabora Online مقابل ONLYOFFICE: اختبار استخدام الموارد وزمن الاستجابة
Collabora Online مقابل ONLYOFFICE: اختبار استخدام الموارد وزمن الاستجابة
غالبًا ما يُطرح اختيار Collabora Online أو ONLYOFFICE Docs كمسألة تتعلق بالميزات أو تنسيق الملفات، لكن فرق البنية التحتية عادةً ما تكتشف قرارًا ثانيًا بعد النشر: ما مقدار وحدة المعالجة المركزية والذاكرة التي يستهلكها كل نظام، وما مدى سرعة استجابة التحرير مع ازدياد زمن الاستجابة وعدد العمليات المتزامنة؟ لا يوجد رقم عالمي موثوق لأي من المنتجين، لأن تعقيد المستند، والخطوط، وعملية التحويل، وزمن استجابة التخزين، وسلوك المتصفح، والخوادم الوكيلة العكسية، وعدد المستندات المفتوحة في الوقت نفسه، كلها عوامل تؤثر على النتيجة.
حتى أكتوبر 2026، لم ينشر أيٌّ من الموردين معيارًا حديثًا ودقيقًا للمقارنة المباشرة بينهما. وهذا أمرٌ بالغ الأهمية. لذا، ينبغي للمقارنة العادلة أن تفصل بين نوعين من الأدلة: إرشادات تحديد الحجم من قِبل المورد، والتي تُبيّن ما يتوقعه كل مشروع منك توفيره، واختبار قابل للتكرار لزمن الاستجابة/الموارد يُجرى على أجهزة متطابقة. صُممت خطة الاختبار أدناه لإنتاج بيانات يمكنك استخدامها في عملية النشر الخاصة بك، دون افتراض أن نتيجة مختبر واحد تنطبق على كل مكان.
تصميم معياري متجاور لبرنامجي Collabora Online و ONLYOFFICE Docs. تعرض لوحات المراقبة المقاييس المطلوب جمعها - وحدة المعالجة المركزية والذاكرة وزمن استجابة الشبكة - بدلاً من قيم المعيار المقاسة.
ما تقوله إرشادات الموارد الرسمية بالفعل
ينشر الموردون معلومات مفيدة حول حجم الموارد، لكن الأرقام ليست متطابقة تمامًا. يتضمن دليل حزمة تطوير البرمجيات (SDK) الخاصة بـ Collabora مثالًا عمليًا لـ Kubernetes/Helm يوصي بطلبات موارد تبلغ 4 وحدات معالجة مركزية و6 جيجابايت من الذاكرة، مع حدود قصوى تبلغ 8 وحدات معالجة مركزية و8 جيجابايت. يصف الدليل نفسه num_prespawn_childrenآلية تُبقي العمليات الفرعية جاهزة لتسريع بدء الجلسات الجديدة على حساب استهلاك ذاكرة إضافية. راجع دليل حزمة تطوير البرمجيات (SDK) الخاصة بـ Collabora Online . كما يُتيح قالب التكوين الحالي لـ Collabora تحديد حد لنسبة الذاكرة وضوابط التزامن لكل مستند؛ ويتوفر المصدر الرسمي للمشروع في قالب تكوين Collabora Online .
تُصدر ONLYOFFICE مستويات مرجعية أكثر وضوحًا لإصدار Docs Community Edition في Docker. تشير إرشاداتها الحالية إلى ضرورة توفر 4 جيجابايت من ذاكرة الوصول العشوائي (RAM) أو أكثر، وتُدرج تكوينات مرجعية تتضمن معالجًا أحادي النواة بتردد 2.8 جيجاهرتز لأقل من 100 مستخدم نشط متزامن، ومعالجين ثنائيي النواة لـ 100-200 مستخدم، ومعالجين رباعيي النواة لـ 200-400 مستخدم، مع الإبقاء على 4 جيجابايت من ذاكرة الوصول العشوائي في هذه التكوينات المرجعية. وتُحذر الشركة صراحةً من أن السعة الفعلية تعتمد على عدد المستندات ونوعها وحجمها. راجع متطلبات ONLYOFFICE Docs Community Edition Docker .
منطقة
التعاون عبر الإنترنت
مستندات ONLYOFFICE
ما الذي يمكن استنتاجه؟
حجم الإنتاج المنشور
يوصي مثال SDK Helm بطلب 4 وحدات معالجة مركزية / 6 جيجابايت، مع حدود تصل إلى 8 وحدات معالجة مركزية / 8 جيجابايت
يبدأ مرجع Docker من 4 جيجابايت من ذاكرة الوصول العشوائي؛ وتتوسع مستويات وحدة المعالجة المركزية مع عدد المستخدمين النشطين المتزامنين
لا يمكن وصف أي من المنتجين بأنه "أخف وزناً" استناداً إلى هذه الأرقام وحدها؛ فافتراضات النشر تختلف.
سلوك بدء التشغيل الدافئ
يمكن لعمليات الأبناء المُنشأة مسبقًا استبدال الذاكرة لبدء الجلسات بشكل أسرع
تتولى خدمات متعددة على جانب الخادم عمليات التحرير والتحويل والأوامر وإنشاء المستندات
يمكن أن يعكس كل من الذاكرة الخاملة وزمن استجابة الفتح الأول بنية النظام وضبطه، وليس فقط كفاءة المحرر.
نموذج التزامن
تتضمن معالجة كل مستند على حدة عناصر تحكم قابلة للتكوين في التزامن
المستخدم النشط المتزامن هو المستخدم الذي لديه مستند مفتوح، بما في ذلك جلسات العرض فقط وفقًا لتعريف البائع.
احسب عدد الجلسات المفتوحة باستمرار قبل مقارنة السعة
لماذا لا تُعد لقطة الشاشة في حالة خمول الذاكرة معيارًا لقياس الأداء؟
تتمثل إحدى المقارنات الشائعة في تشغيل كلا الحاويتين دون فتح أي مستندات، ثم اعتبار الحاوية ذات استهلاك الذاكرة العشوائية الأقل هي الفائزة. لكن هذه الطريقة تقيس فقط الحد الأدنى من استهلاك الذاكرة، وتتجاهل العمليات الأساسية: فتح الملف، وتحويله عند الحاجة، وعرض الصفحات أو الجداول، ونقل التغييرات، وإعادة حساب الجداول، وتشغيل عدة محررين، وحفظ النتيجة في وحدة التخزين.
يُتيح نموذج عمليات Collabora إمكانية تجهيز العمليات الفرعية مسبقًا، مما قد يزيد من وقت الخمول مع تقليل التأخير قبل أن يصبح المستند جاهزًا للاستخدام. يفصل ONLYOFFICE تحرير المستندات عن خدمات أخرى مثل التحويل؛ وتصف وثائق بنيته محرر المستندات، وخدمة التحرير، وخدمة الأوامر، وخدمة التحويل، وخدمة الإنشاء. راجع قسم " كيف يعمل ONLYOFFICE Docs" . بعبارة أخرى، يُعدّ RSS الأساسي مقياسًا تشغيليًا مفيدًا، ولكنه غير كافٍ للتنبؤ بالسرعة التي يراها المستخدم.
إعداد اختبار عادل للموارد وزمن الاستجابة
شغّل المنتجين واحدًا تلو الآخر على نفس الجهاز المضيف أو على جهازين افتراضيين متطابقين في الإعدادات. تجنّب اختبار أحدهما على جهاز مضيف مُهيأ مسبقًا مع ملفات مُخزّنة مؤقتًا والآخر مباشرةً بعد بدء التشغيل. حافظ على تطابق توزيعة لينكس، وإصدار دوكر، وحصة وحدة المعالجة المركزية، وحد الذاكرة، وفئة التخزين، والخادم الوكيل العكسي، وإنهاء TLS، وإصدار المتصفح، ومسار تخزين المستندات.
استخدم ثلاثة أنواع من أعباء العمل المتعلقة بالمستندات
مستند نصي: ملف DOCX نموذجي يحتوي على عناوين وجداول وصور وتغييرات متعقبة وتعليقات.
جدول البيانات: ملف XLSX يحتوي على صيغ، وتنسيق شرطي، وعدة أوراق عمل، وبيانات كافية لإجراء إعادة حساب ذات مغزى.
العرض التقديمي: ملف PPTX يحتوي على صور ورسوم بيانية وشرائح متعددة بدلاً من مجموعة شرائح فارغة تقريبًا.
استخدم الملفات نفسها لكلا النظامين الأساسيين. إذا تطلّب ملفٌ ما تحويل تنسيق في أحد البرامج، فسجّل هذه المعلومة لأنّ التحويل قد يستغرق وقتًا طويلاً لفتح الملف. لا تُحسّن ملفًا خصيصًا لمحررٍ واحد ثمّ تتعامل مع النتيجة كمقارنة عامة بين النظامين.
اختبر على أكثر من مستوى تزامن واحد
التسلسل العملي الأمثل هو فتح 1، 5، 10، و20 محررًا في وقت واحد، متبوعًا بمستوى أعلى يتوافق مع ذروة الأداء المتوقعة. يُقصد بـ "المستخدم" في كل تجربة نفس الشيء: علامة تبويب محرر مفتوحة بالكامل. كرر كل مستوى ثلاث مرات على الأقل بعد تجربة تمهيدية، وسجل متوسط النتائج بالإضافة إلى أبطأها. هذا يقلل من احتمالية تأثير الارتفاعات المفاجئة في الخلفية على النتائج.
مقاييس الموارد التي يجب تسجيلها
يوفر Docker طبقة أولى محايدة من بيانات القياس عن بُعد. تشرح وثائق إحصائيات Docker الرسميةdocker stats أن هذه البيانات تُبلغ عن نسبة استخدام وحدة المعالجة المركزية، واستخدام الذاكرة، وعمليات الإدخال/الإخراج للشبكة، وعمليات الإدخال/الإخراج للكتل، ومعرفات العمليات (PIDs). يمكنك تسجيل بث مباشر أثناء العمل، بالإضافة إلى عينة بدون بث عند نقاط تفتيش محددة.
لكل مستوى من مستويات التزامن، سجّل استهلاك الذاكرة الخاملة قبل فتح أي شيء، واستهلاك الذاكرة في حالة الاستقرار بعد فتح جميع المستندات، وذروة استخدام وحدة المعالجة المركزية أثناء الفتح، واستهلاك وحدة المعالجة المركزية بعد استقرار الجلسات، واستهلاك الذاكرة بعد إغلاق كل جلسة. راقب أيضًا ما إذا كانت الذاكرة تعود إلى مستواها الأساسي تقريبًا بعد فترة تهدئة. لا تُعدّ القيمة الأعلى بعد الاختبار مؤشرًا على وجود تسريب تلقائيًا - إذ يمكن أن تظل ذاكرة التخزين المؤقت والذاكرة المشتركة مفيدة - ولكن ارتفاع الحد الأدنى باستمرار عبر دورات متطابقة متكررة يستدعي التحقيق.
لا تقارن نسب استخدام الحاويات فقط إذا كانت إحداها تمتلك حدودًا مختلفة لوحدة المعالجة المركزية أو الذاكرة. سجّل حدود المضيف أو مجموعة التحكم (cgroup) الفعلية مع نتائج الاختبار. يُذكر أن بيانات ذاكرة نظام لينكس في Docker تتضمن أيضًا تفاصيل دقيقة تتعلق بحساب ذاكرة التخزين المؤقت، لذا استخدم بيئة Docker ومجموعة التحكم نفسها لكلا المنتجين.
كيفية قياس زمن الاستجابة المفتوحة
حدد زمن استجابة الفتح قبل الاختبار. التعريف المقبول هو الوقت المستغرق من لحظة فتح المستخدم للمحرر حتى يصبح جاهزًا للإدخال بشكل واضح، وحتى يستقر محتوى المستند بما يكفي لبدء الكتابة. قِس نفس المؤشر لكلا المنتجين. قد يكون تسجيل الشاشة مع الطوابع الزمنية أكثر دقة للمقارنة من الاعتماد على الأحداث الداخلية الخاصة بكل منتج.
اجمع نوعين من زمن الاستجابة عند فتح الملفات. يبدأ الفتح البارد بعد إعادة تشغيل حاوية المكتب ومسح جلسة الاختبار. أما الفتح الدافئ فيكرر نفس الملف دون إعادة تشغيل الخدمة. يُبرز إعداد ما قبل التشغيل في Collabora أهمية هذا التمييز، لأن زيادة عدد العمليات الفرعية المنتظرة قد تُقلل من زمن بدء التشغيل مع زيادة استهلاك الذاكرة. إذا قمت بضبط هذا الإعداد num_prespawn_children، فاعرض قيمته بجانب النتائج بدلاً من إخفائها.
كيفية قياس زمن استجابة التعاون
في التحرير التعاوني الفوري، لا يُعدّ اختبار الاتصال ICMP العادي المقياس الأمثل. قِس التأخير بين إجراء تعديل في المتصفح (أ) وظهور التغيير في المتصفح (ب). استخدم ملفي تعريف متصفحين منفصلين أو جهازين مختلفين، وقم بمزامنة ساعاتهما. سجّل ما بين 20 إلى 50 تعديلًا بسيطًا، مثل إضافة حرف إلى الفقرة نفسها، ثم احسب متوسط التأخير المرئي وقيمته المئوية الخامسة والتسعين.
يؤكد وصف التحرير التعاوني الرسمي في ONLYOFFICE أن التغييرات تنتقل من المحرر إلى خدمة تحرير المستندات، ثم إلى المحرر الآخر. راجع سير عمل التحرير التعاوني في ONLYOFFICE . كما يكشف تكوين الخادم عن إعدادات متعلقة بـ WebSocket، بما في ذلك سلوك إعادة الاتصال والحد الأقصى لحجم البيانات المرسلة، في مرجع تكوين خادم ONLYOFFICE . وبالمثل، يعتمد Collabora على حركة مرور WebSocket المستمرة عبر الوكيل العكسي، لذا يجب التعامل مع تخزين الوكيل المؤقت، وسلوك المهلة، وإنهاء TLS، وزمن استجابة الشبكة (RTT) كجزء من بيئة الاختبار وليس كتفاصيل ثانوية.
أضف تأخير الشبكة المتحكم به
إذا كان المستخدمون يعملون عن بُعد، فأعد اختبار التعاون مع ضبط زمن الاستجابة ذهابًا وإيابًا، مثل 20 مللي ثانية، و80 مللي ثانية، و150 مللي ثانية تقريبًا. طبّق نفس إعدادات الشبكة على كلا النظامين، ووثّق بدقة مكان تطبيقها. هذا يكشف فرقًا قد تخفيه معايير الشبكة المحلية: قد يبدو أداء المحرر ممتازًا عند زمن استجابة ذهابًا وإيابًا يتراوح بين 1 و5 مللي ثانية، ولكنه يصبح أقل استجابة بشكل ملحوظ في الفروع أو الفرق الدولية.
يحتاج توفير زمن الاستجابة إلى قياس خاص به.
لا يُعدّ الحفظ مرادفًا لزمن استجابة الكتابة. توثّق ONLYOFFICE سير عملٍ تقوم فيه خدمة التحرير بتجميع التغييرات وإرسال إشعار إلى خدمة التخزين بعد انتهاء التحرير؛ وتشير وثائقها إلى تأخير افتراضي لبدء التحويل مدته خمس ثوانٍ، وتوضح أن التوقيت النهائي يعتمد أيضًا على وقت التحويل، وتعقيد الملف، وأداء الخادم. راجع وثائق حفظ الملفات في ONLYOFFICE . هذا يعني أنه لا ينبغي تفسير ملاحظة "استغرق الحفظ عدة ثوانٍ" تلقائيًا على أنها تأخير في التفاعل.
بالنسبة لكلا المنتجين، قِس وقت اكتمال الحفظ من لحظة انتهاء آخر محرر حتى تأكيد وجود الملف المُحدَّث في وحدة التخزين الأساسية. حافظ على التخزين على نفس مسار الشبكة ونفس فئة القرص. وإلا، فقد يُعزى بطء Nextcloud أو ownCloud أو مخزن الكائنات أو قاعدة البيانات أو الخادم الوكيل العكسي إلى حزمة برامج Office.
ورقة النتائج: الأرقام المهمة
متري
سجل في
لماذا يُعد ذلك مهماً؟
الذاكرة الخاملة
لا توجد مستندات مفتوحة
التكلفة الأساسية للخوادم الصغيرة
ذاكرة ثابتة لكل عبء عمل
1، 5، 10، 20+ محرر مفتوح
يُظهر سلوك التوسع بشكل أفضل من RSS الخامل
ذروة وحدة المعالجة المركزية
أثناء فتح المستند وإعادة حساب جدول البيانات
يكشف عن متطلبات سعة الانفجار
زمن استجابة الفتح البارد
بعد إعادة تشغيل الخدمة
يلتقط تكلفة بدء التشغيل/إنشاء العمليات
زمن استجابة الفتح الدافئ
فتح الملف بشكل متكرر
يُظهر استجابة طبيعية للجلسات المتكررة
تعديل الانتشار ص50/ص95
التحرير المشترك بين مستخدمين
مقاييس التأخير المتوقع في التعاون
حفظ الإكمال
آخر محرر يُغلق أو يُنهي عمله
يفصل وقت الثبات عن زمن الاستجابة التفاعلي
كيفية تفسير النتيجة
إذا كان برنامج Collabora يستهلك ذاكرة خاملة أكثر في إعداداتك ولكنه يُقلل من زمن استجابة فتح الملفات، فقد يكون هذا خيارًا مقبولًا إذا كان المستخدمون يفتحون المستندات بشكل متكرر وكان الخادم يمتلك ذاكرة وصول عشوائي (RAM) فائضة. أما إذا أظهر برنامج ONLYOFFICE معدل استخدام أساسي أقل ولكن ارتفاعات أعلى في استخدام وحدة المعالجة المركزية (CPU) أثناء التحويل، فقد يكون هامش استخدام وحدة المعالجة المركزية (CPU) أهم من الذاكرة. كما أن الأنماط المعاكسة ممكنة أيضًا؛ والهدف هو ربط كل منحنى من منحنيات الموارد بحدث مرئي للمستخدم.
بالنسبة للتثبيتات الصغيرة ذاتية الاستضافة، ركّز على استهلاك الذاكرة في وضع الخمول، ووقت فتح الملف لأول مرة، وما إذا كان مستند واحد أو مستندان كبيران يتسببان في تبديل الملفات. أما بالنسبة للنشر التجاري الذي يضم عشرات المحررين النشطين، فأعطِ الأولوية لمعدل نمو الذاكرة، وتشبع وحدة المعالجة المركزية، وتأخير التحرير المشترك (p95)، والتعافي بعد التحميل. بالنسبة للمستخدمين الموزعين جغرافيًا، قد تفوق أهمية زمن استجابة الشبكة (RTT) وتكوين الخادم الوكيل (Proxy) الاختلافات الطفيفة في جانب الخادم.
لذا، فإن المنتج الأمثل هو الذي يلتزم بميزانية المعالج والذاكرة المتاحة لديك، مع تحقيق زمن الاستجابة المطلوب في مستنداتك الحقيقية. صفحات تحديد الأحجام من قِبل الموردين هي مجرد نقاط انطلاق، وليست نتائج قياس أداء. شغّل نفس عبء العمل، وحافظ على بيئة اختبار مضبوطة، وانشر إعدادات الاختبار بجانب الأرقام، وتجنّب تعميم قراءة واحدة للذاكرة الخاملة لاستخلاص استنتاج حول الأداء العام.