Jak skonfigurować limity czasu bezczynności dla sesji edycyjnych Collabora

Collabora Online ma kilka ustawień, które brzmią jak „limit czasu bezczynności”, ale kontrolują one różne zachowania. Jeśli edytor przyciemnia ekran lub przestaje aktualizować, podczas gdy użytkownik nadal pracuje, dostosuj ustawienie braku aktywności dla każdego widoku. Jeśli dokument pozostaje załadowany po opuszczeniu go przez wszystkich, dostosuj limit czasu dla każdego dokumentu. Jeśli edytor faktycznie się rozłącza, sprawdź limit czasu WebSocket odwrotnego serwera proxy przed zmianą zasad bezczynności Collabora.

Aktualny szablon konfiguracji Collabora Online dokumentuje 15-minutowy limit czasu bezczynności dla każdego widoku, 5-minutowy limit czasu, gdy karta przeglądarki jest nieaktywna, oraz godzinny limit czasu przed wyładowaniem bezczynnego dokumentu. Te wartości domyślne mogą się różnić w zależności od wersji i pakietu, dlatego przed wprowadzeniem zmian należy sprawdzić konfigurację dołączoną do zainstalowanej wersji. Poniższe wartości odnoszą się do aktualnego szablonu sprawdzonego na potrzeby tego przewodnika i nie stanowią gwarancji dla każdego wdrożenia CODE lub w przedsiębiorstwie.

Wybierz ustawienie w oparciu o oczekiwane zachowanie

Collabora dokumentuje znaczenie i ustawienia domyślne w swoim aktualnym szablonie konfiguracji coolwsd oraz dokumentacji konfiguracyjnej . Limit czasu bezczynności dla danego widoku nie jest tym samym, co zamknięcie konta lub cofnięcie dostępu: przyciemnia widok i zatrzymuje aktualizacje. Limit czasu dla danego dokumentu zwalnia bezczynny proces dokumentu; nie jest to licznik czasu, który powinien zakończyć działanie osoby aktywnie edytującej.

Zalecane punkty początkowe

• Zapobiegaj zbyt wczesnemu wygaszaniu aktywnych kart użytkowników: zwiększ per_view.idle_timeout_secsodstęp czasu z domyślnego ustawienia do zmierzonego, np. 1800 sekund (30 minut). To praktyczny punkt wyjścia, a nie uniwersalne zalecenie.
• Pozwól użytkownikom przełączać się między kartami, zachowując jednocześnie aktualność dokumentu: podnoś je per_view.out_of_focus_timeout_secsosobno. Nie podnoś ich tylko dlatego, że użytkownicy są nieaktywni na aktywnej karcie.
• Zmniejsz użycie pamięci po porzuceniu dokumentów: pozostaw wartości na widok bez zmian i rozważ obniżenie ich per_document.idle_timeout_secspo upewnieniu się, że dokument jest rzeczywiście bezczynny i że zapisy w pamięci masowej są prawidłowe.
• Napraw rozłączenie o stałym czasie trwania: sprawdź limit czasu WebSocket serwera proxy, ruchu przychodzącego lub modułu równoważenia obciążenia. Zmiana ustawienia przyciemniania dla każdego widoku nie naprawi WebSocket zamkniętego przez serwer proxy.
• Zachowaj częste zapisy: pozostaw ustawienia zapisu w czasie bezczynności i automatycznego zapisu na dotychczasowym poziomie, chyba że masz konkretny powód, aby je zmienić.

Zmień ustawienia w pliku coolwsd.xml

W przypadku instalacji opartej na pakiecie znajdź aktywny coolwsd.xmlplik używany przez działającą usługę. Typowe lokalizacje to /etc/coolwsd/coolwsd.xml, ale ścieżki różnią się w zależności od dystrybucji i starszych wersji. Nie zakładaj, że edycja przykładowego pliku lub nieużywanej zamontowanej kopii zmieni działającą usługę.

Utwórz kopię zapasową aktywnego pliku, a następnie edytuj tylko istotne wartości w istniejących sekcjach <per_view>i <per_document>. Na przykład, ten fragment ustawia 30-minutowy limit czasu dla nieaktywnego użytkownika, 15-minutowy limit czasu dla karty w tle i dwugodzinne rozładowanie bezczynnego dokumentu:

<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>

To fragment, a nie kompletna konfiguracja zastępcza. Zachowaj atrybuty, komentarze, zagnieżdżanie i inne elementy w pliku dołączonym do Twojej wersji; niektóre kompilacje wymagają dodatkowych atrybutów XML. Jeśli chcesz zmienić tylko przyciemnianie, gdy karta jest aktywna, edytuj tylko wartość bezczynności dla każdego widoku. Jednoczesne zwiększenie wartości dla każdego widoku i wartości rozładowania dokumentu utrudnia ustalenie, które ustawienie rozwiązało problem.

Sprawdź poprawność pliku XML za pomocą narzędzi konfiguracyjnych obsługiwanych przez wdrożenie, a następnie uruchom ponownie lub przeładuj Collaborę, korzystając z metody udokumentowanej dla danego pakietu. Sprawdź dzienniki uruchamiania pod kątem błędów analizy konfiguracji i upewnij się, że uruchomiony proces załadował odpowiedni plik. Zmiana ustawień, która nie została wprowadzona w aktywnym procesie, nie przyniesie żadnego efektu.

Ustaw te same opcje w Dockerze lub Kubernetesie

W obrazie Dockera w Collabora administratorzy często przekazują opcje konfiguracji za extra_paramspomocą --o:składni opcji. Poniższa wartość w stylu Compose ilustruje ten sam przykład:

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

Użyj tego tylko wtedy, gdy Twój obraz i wykres wdrożenia obsługują tę opcję extra_params. W przypadku Kubernetes, Helm lub instalacji zarządzanej przez operatora, wpisz opcje w polu konfiguracji obsługiwanej przez wykres lub zasób niestandardowy, zamiast edytować wygenerowany plik kontenera. Podczas zmiany zmiennych środowiskowych w Compose, utwórz lub wdróż usługę ponownie, aby nowe wartości dotarły do ​​kontenera; zwykły restart może ponownie wykorzystać istniejącą konfigurację kontenera.

Nie należy ustawiać tej samej opcji w miejscach powodujących konflikt, takich jak zamontowany plik XML i parametr środowiskowy, bez sprawdzenia reguł pierwszeństwa dla danej wersji. Po ponownym wdrożeniu należy sprawdzić dzienniki uruchamiania kontenera i aktywną konfigurację. W przypadku różnic w nazwach opcji lub zachowaniu kontenera, odpowiednimi odniesieniami są repozytorium źródłowe projektu Collabora oraz dokumentacja wdrożenia z dopasowaną wersją.

Sprawdź osobno przekroczenia limitu czasu serwera proxy odwrotnego

Edytor Collabora wykorzystuje WebSocket do bieżącej komunikacji w przeglądarce. Serwer proxy może zamknąć w innym przypadku prawidłowy WebSocket, nawet gdy limity czasu dla dokumentu i widoku Collabora są ustawione znacznie dłużej. W takim przypadku użytkownicy mogą zobaczyć komunikat o rozłączeniu, prośbę o ponowne połączenie lub edytor, który przestaje otrzymywać aktualizacje, zamiast po prostu przyciemnionego widoku.

Porównaj limity czasu odczytu/wysyłania serwera proxy, limity czasu bezczynności dla ruchu przychodzącego lub modułu równoważenia obciążenia w chmurze oraz zamierzone zachowanie sesji w Collabora. Limity czasu muszą być zgodne na całej trasie. Przewodnik po ustawieniach serwera proxy Collabora zawiera konfigurację serwera proxy WebSocket i przykłady połączeń długoterminowych. Zastosuj wskazówki odpowiednie dla konkretnego serwera proxy i zwolnij; nie kopiuj bezmyślnie starego bloku Nginx do innego serwera proxy lub niepowiązanej trasy.

Przydatną wskazówką jest schemat awarii. Jeśli użytkownicy widzą tylko przyciemniony widok nieaktywnych, sprawdź per_view. Jeśli wszyscy użytkownicy rozłączają się mniej więcej w tym samym czasie, sprawdź logi proxy i modułu równoważenia obciążenia dla tego znacznika czasu. Jeśli dokument zamyka się dopiero po opuszczeniu go przez wszystkich uczestników, bardziej istotny jest limit czasu dla danego dokumentu.

Testuj po jednym przekroczeniu limitu czasu na raz

1. Zapisz bieżące wartości z aktywnej konfiguracji i zanotuj wersję Collabora oraz metodę wdrożenia.
2. Otwórz dokument testowy z dwoma użytkownikami lub dwiema sesjami przeglądarki, aby zobaczyć zarówno widok aktywny, jak i nieaktywny.
3. Zmień tylko limit czasu odpowiadający objawowi. Na przykład, aby zapobiec przyciemnianiu w aktywnej, ale cichej karcie, dostosuj per_view.idle_timeout_secstylko limit czasu.
4. Uruchom ponownie lub przeprowadź ponowne wdrożenie przy użyciu obsługiwanej metody, a następnie sprawdź, czy nowa wartość pojawia się w aktywnej konfiguracji lub dziennikach uruchamiania.
5. Poczekaj, aż minie poprzedni próg. Sprawdź, czy widok nadal się przyciemnia, drugi użytkownik nadal otrzymuje aktualizacje, a zmiany nadal się zapisują.
6. Zamknij wszystkie widoki dokumentu testowego i sprawdź, czy nieaktywny dokument rozładowuje się w zamierzonym zakresie.
7. Sprawdź dzienniki Collabora i proxy pod kątem zamknięcia protokołu WebSocket, błędów analizy XML, nieudanych zapisów lub nieoczekiwanego czyszczenia procesów.

Nie testuj zmiany na niezapisanym dokumencie produkcyjnym. Upewnij się, że zmodyfikowane pliki zapisują się w zapleczu pamięci masowej, zanim pozwolisz na zwolnienie bezczynnego procesu dokumentu. Jeśli problem występuje tylko w przypadku niezapisanych zmian, sprawdź błędy automatycznego zapisu i pamięci masowej jako osobny problem, zamiast wydłużać każdy limit czasu.

Równowaga między wygodą, wykorzystaniem zasobów i niezawodnością

Dłuższe limity czasu dla każdego widoku są odpowiednie dla zespołów, które przeglądają dokumenty w przerwach lub pracują na kilku kartach przeglądarki. Krótsze wartości mogą sprawić, że nieaktywne widoki przestaną się aktualizować szybciej, co może ograniczyć aktywność w tle, ale mogą przerwać pracę czytelnika, który nadal przegląda dokument. Limit czasu dla każdego dokumentu to osobna opcja zarządzania zasobami: jego wydłużenie powoduje, że nieużywane dokumenty są ładowane dłużej, a skrócenie może wymagać ponownego załadowania po powrocie użytkownika.

W przypadku większości wdrożeń należy zmienić najmniejszą liczbę ustawień wymaganą do dopasowania do zaobserwowanego zachowania. Zachowaj interwały zapisu, ustaw rozsądny przedział czasu bezczynności dla każdego widoku dla zespołu, zachowaj celowy limit czasu dla karty w tle i dostosuj limity WebSocket serwera proxy tylko wtedy, gdy logi lub dane czasowe wskazują na problem z warstwą połączenia. Po aktualizacji należy ponownie sprawdzić szablon konfiguracji zainstalowanej wersji, ponieważ ustawienia domyślne i obsługiwane mogą ulec zmianie.