كيفية ضبط مهلة الخمول لجلسات التحرير في Collabora

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

يُوثّق نموذج تكوين Collabora Online الحالي مهلة 15 دقيقة لكل عرض في حالة الخمول، ومهلة 5 دقائق عند عدم التركيز على علامة تبويب المتصفح، ومهلة ساعة واحدة قبل إلغاء تحميل المستند الخامل. قد تختلف هذه الإعدادات الافتراضية باختلاف الإصدار والتغليف، لذا يُرجى مراجعة التكوين المرفق مع الإصدار المُثبّت لديك قبل إجراء أي تغييرات. تشير القيم المذكورة أدناه إلى النموذج الحالي المُستخدم في هذا الدليل، ولا تُعدّ ضمانًا لجميع عمليات نشر CODE أو المؤسسات.

اختر الإعداد بناءً على السلوك الذي تريده

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

نقاط البداية الموصى بها

• لمنع تعتيم علامات التبويب النشطة للمستخدمين قبل الأوان، يُنصح بزيادة per_view.idle_timeout_secsالفترة الزمنية من القيمة الافتراضية المُثبّتة إلى فترة زمنية محددة، مثل 1800 ثانية (30 دقيقة). هذه نقطة بداية عملية، وليست توصية عامة.
• اسمح للمستخدمين بالتبديل بين علامات التبويب مع الحفاظ على تحديث المستند: ارفع مستوى التنبيه per_view.out_of_focus_timeout_secsبشكل منفصل. لا ترفع مستوى التنبيه لمجرد أن المستخدمين غير نشطين في علامة تبويب محددة.
• قلل من استخدام الذاكرة بعد التخلي عن المستندات: اترك قيم العرض لكل معاينة كما هي وفكر في خفضها per_document.idle_timeout_secs، بعد التأكد من أن المستند خامل بالفعل وأن عمليات حفظ التخزين سليمة.
• لإصلاح انقطاع الاتصال ذي المدة المحددة: تحقق من مهلة WebSocket الخاصة بالخادم الوكيل أو بوابة الدخول أو موازن الأحمال. لن يؤدي تغيير إعداد التعتيم لكل عرض إلى إصلاح WebSocket الذي يغلقه الخادم الوكيل.
• حافظ على عمليات الحفظ المتكررة: اترك قيم الحفظ التلقائي والحفظ أثناء الخمول على إعداداتها الحالية ما لم يكن لديك سبب منفصل لتغييرها.

قم بتغيير الإعدادات في ملف coolwsd.xml

في حالة التثبيت باستخدام حزمة، ابحث عن coolwsd.xmlالملف النشط الذي يستخدمه البرنامج قيد التشغيل. تشمل المواقع الشائعة [ /etc/coolwsd/coolwsd.xmlالمسارات]، ولكن تختلف المسارات بين التوزيعات والإصدارات القديمة. لا تفترض أن تعديل ملف عينة أو نسخة غير مستخدمة مثبتة سيؤثر على البرنامج قيد التشغيل.

قم بعمل نسخة احتياطية من الملف النشط، ثم عدّل القيم ذات الصلة فقط ضمن الأقسام الموجودة <per_view>. <per_document>على سبيل المثال، يحدد هذا المقتطف مهلة 30 دقيقة للمستخدم غير النشط، ومهلة 15 دقيقة لعلامة التبويب في الخلفية، وساعتين لإلغاء تحميل المستند الخامل.

<per_view>
    <idle_timeout_secs>1800</idle_timeout_secs>
    <out_of_focus_timeout_secs>900</out_of_focus_timeout_secs>
</per_view>
<per_document>
    <idle_timeout_secs>7200</idle_timeout_secs>
</per_document>

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

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

قم بتعيين نفس الخيارات في Docker أو Kubernetes

في صورة Docker الخاصة بـ Collabora، يقوم المسؤولون عادةً بتمرير خيارات التكوين باستخدام extra_paramsصيغة --o:الخيارات. توضح القيمة التالية، المصممة على نمط Compose، المثال نفسه:

extra_params=--o:per_view.idle_timeout_secs=1800 --o:per_view.out_of_focus_timeout_secs=900 --o:per_document.idle_timeout_secs=7200

استخدم هذا الخيار فقط إذا كانت صورتك ومخطط النشر يدعمان ذلك extra_params. بالنسبة لـ Kubernetes أو Helm أو التثبيت المُدار من قِبل المُشغل، ضع الخيارات في حقل التكوين المدعوم للمخطط أو المورد المُخصص بدلاً من تعديل ملف الحاوية المُنشأ. عند تغيير متغيرات البيئة في Compose، أعد إنشاء الخدمة أو إعادة نشرها حتى تصل القيم الجديدة إلى الحاوية؛ قد يؤدي إعادة التشغيل العادية إلى إعادة استخدام تكوين الحاوية الحالي.

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

تحقق من مهلات الخادم الوكيل العكسي بشكل منفصل

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

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

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

اختبر مهلة واحدة في كل مرة

1. سجل القيم الحالية من التكوين النشط ولاحظ إصدار Collabora وطريقة النشر.
2. افتح مستند اختبار باستخدام مستخدمين اثنين أو جلستين للمتصفح حتى تتمكن من ملاحظة كل من العرض النشط وغير النشط.
3. غيّر فقط مهلة الانتظار التي تتناسب مع العرض. على سبيل المثال، لمنع التعتيم في علامة تبويب مركزة ولكنها هادئة، اضبط per_view.idle_timeout_secsفقط.
4. أعد التشغيل أو أعد النشر من خلال الطريقة المدعومة، ثم تأكد من ظهور القيمة الجديدة في سجلات التكوين النشط أو سجلات بدء التشغيل.
5. انتظر بعد تجاوز الحد السابق. تأكد مما إذا كان العرض لا يزال خافتاً، وما إذا كان المستخدم الثاني لا يزال يتلقى التحديثات، وما إذا كانت التعديلات تستمر في الحفظ.
6. أغلق جميع طرق عرض مستند الاختبار ولاحظ ما إذا كان المستند الخامل يتم تفريغه ضمن النطاق المقصود.
7. تحقق من سجلات Collabora والوكيل بحثًا عن إغلاق WebSocket، وأخطاء تحليل XML، وعمليات الحفظ الفاشلة، أو تنظيف العمليات غير المتوقع.

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

وازن بين الراحة واستخدام الموارد والموثوقية

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

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