تخلص من تأخر التحرير المشترك في ONLYOFFICE عن طريق تحديد نقطة الاختناق

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

1. قم بإعادة إنتاج التأخير وتحقق من الخادم قبل ضبطه.

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

على مضيف Docker، حدد حاوية خادم المستندات وراقب استخدامها للموارد أثناء حدوث التأخير:

docker ps
 docker stats <container_name_or_id>

ابحث عن استهلاك مستمر لوحدة المعالجة المركزية، أو اقتراب الذاكرة من الحد الأقصى للمضيف أو الحاوية، أو نشاط تبديل الذاكرة، أو إعادة تشغيل الحاوية. تحقق أيضًا من مساحة القرص على المضيف وعمليات الإدخال/الإخراج إذا توقفت عمليات الحفظ أو تحميل المستندات. الارتفاع المفاجئ في الاستهلاك أقل دلالة من وجود اختناق في الذاكرة يتزامن مع بطء التحرير. تشير صفحة استكشاف أخطاء Docker الخاصة بـ ONLYOFFICE إلى أن استخدام الذاكرة يرتفع مع المستندات المفتوحة والمستخدمين المتزامنين؛ حيث تُشير إلى أن 2-4 جيجابايت هو المعدل الطبيعي لخادم به بضع عشرات من المستخدمين النشطين، ولكن هذا لا يضمن الحجم الأمثل للذاكرة.

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

2. في حال إعادة اتصال المحررين، افحص الخادم الوكيل ومسار الشبكة.

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

تحقق من سجلات الوصول والأخطاء الخاصة بالخادم الوكيل خلال جلسة واحدة تعاني من بطء في الاتصال. تأكد من أن إعداداتك تُعيد توجيه رؤوس HTTP Upgrade وConnection، مع الحفاظ على المضيف والبروتوكول الأصليين. بالنسبة لـ NGINX، قارن إعداداتك مع أمثلة الخادم الوكيل الرسمية من ONLYOFFICE ؛ حيث تُشير الوثائق تحديدًا إلى الرؤوس المُعاد توجيهها X-Forwarded-Proto. X-Forwarded-Hostلا تقم بنسخ نموذج كامل إذا كان إنهاء TLS أو بادئة المسار أو بنية الخادم الوكيل لديك مختلفًا.

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

3. اختر الوضع السريع أو الوضع الصارم لسير العمل، وليس كحل لمشكلة الخادم.

يُقدّم ONLYOFFICE خيارين للتحرير التعاوني: التحرير السريع، وهو الوضع الافتراضي الذي يُظهر تعديلات المستخدمين الآخرين في الوقت الفعلي، والتحرير التعاوني المُحكم، الذي يُبقي التغييرات محفوظة حتى يقوم المستخدم بحفظها. توضح وثائق التحرير التعاوني الفرق في طريقة عرض التغييرات. يُناسب التحرير المُحكم الفرق التي تُفضّل مراجعة التغييرات وتطبيقها على دفعات؛ بينما يُعدّ التحرير السريع الخيار الأمثل عندما تكون الرؤية المشتركة الفورية ضرورية.

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

4. قم بقياس الضغط فقط بعد تحديد سعة الضغط من خلال القياسات

إذا حدث تأخير في عرض المستندات والمستخدمين مع استمرار استهلاك وحدة المعالجة المركزية بالكامل، أو محدودية الذاكرة، أو إعادة تشغيل الحاويات، فقم أولاً بتوفير موارد كافية لخادم المستندات على المضيف، وتأكد من أن حدود Docker لا تؤثر سلبًا على أداء المضيف. ثم أعد الاختبار. يشير مرجع Docker المنشور لإصدار Community إلى متطلبات ذاكرة وصول عشوائي (RAM) بسعة 4 جيجابايت ومساحة تخزين تختلف باختلاف عدد المستخدمين المتزامنين؛ بالنسبة لأكثر من 400 مستخدم نشط متزامن، يوصي المرجع بنشر مجموعة خوادم ويشير إلى Kubernetes. استخدم هذه الأرقام كمرجع تخطيطي، وليس كضمانة على أن خادمًا معينًا سيدعم حمل عمل محدد.

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

تحقق من الإصلاح باستخدام نفس اختبار التحرير

أعد إجراء عملية التحرير الأصلية باستخدام مستخدمين اثنين، وذلك باستخدام نفس المستند ومسار العميل ونفس الحمل التقريبي. تأكد من استجابة الكتابة لكلا المحررين، وأن التغييرات تظهر باستمرار في وضع التحرير المشترك المُختار، وأن عمليات إعادة الاتصال أو إعادة تشغيل الحاوية قد توقفت. راقب docker statsأثناء إعادة الاختبار، وتحقق من سجلات الوكيل لمعرفة ما إذا كانت المشكلة متعلقة بالاتصال. إذا نجح اختبار صغير، ولكن جلسات ساعات الذروة لا تزال تعاني من التأخير، فاجمع صورة الحاوية/إصدارها، وإصدارات المضيف وDocker، ووحدات التخزين المُثبتة، ومخططات الموارد، والسجلات ذات الصلة قبل تغيير المزيد من الإعدادات؛ يشرح دليل تسجيل التصحيح الرسمي كيفية تمكين سجلات التصحيح المؤقتة في Docker. خفّض مستوى التسجيل المُفصّل بعد جمع الأدلة لأنه يزيد من حجم السجلات.

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