Zatrzymaj opóźnienia we współedycji ONLYOFFICE, znajdując wąskie gardło

Jeśli współedycja w ONLYOFFICE wydaje się powolna na samodzielnie hostowanym serwerze Docker, najpierw sprawdź, czy opóźnienie jest związane z serwerem, ścieżką sieciową, czy konkretnym dokumentem. Przed wprowadzeniem jakichkolwiek zmian zmierz tę samą sesję edycji: sprawdź wykorzystanie zasobów kontenera i hosta, a następnie upewnij się, że odwrotny serwer proxy poprawnie przekazuje połączenie z edytorem na żywo. Dodaj procesor, pamięć lub inną infrastrukturę tylko wtedy, gdy pomiary te wskażą limit wydajności.

1. Odtwórz opóźnienie i sprawdź serwer przed jego dostrojeniem

Poproś dwóch redaktorów o otwarcie tego samego dokumentu i jednoczesne wprowadzenie drobnej zmiany. Zwróć uwagę, czy obaj użytkownicy mają opóźnienia w pisaniu, czy u jednego z nich aktualizacje pojawiają się z opóźnieniem oraz czy problem występuje w przypadku każdego pliku, czy tylko w przypadku jednego, dużego lub złożonego pliku. To proste porównanie pomaga odróżnić ogólny problem z usługą od obciążenia pracą związanego z konkretnym dokumentem.

Na hoście Docker zidentyfikuj kontener Serwera dokumentów i obserwuj jego wykorzystanie zasobów, gdy wystąpi opóźnienie:

docker ps
 docker stats <container_name_or_id>

Zwróć uwagę na utrzymujące się nasycenie procesora, zbliżającą się do limitu pamięci hosta lub kontenera, aktywność wymiany lub restart kontenera. Sprawdź również miejsce na dysku hosta i operacje wejścia/wyjścia, jeśli zapisywanie lub ładowanie dokumentów jest wstrzymane. Krótki skok jest mniej rozstrzygający niż wąskie gardło związane z powolnymi edycjami. Strona rozwiązywania problemów z Dockerem ONLYOFFICE informuje, że użycie pamięci rośnie wraz z otwartymi dokumentami i jednoczesną liczbą użytkowników; daje to 2–4 GB jako normę dla serwera z kilkudziesięcioma aktywnymi użytkownikami, ale nie jest to uniwersalna gwarancja rozmiaru.

Pamiętaj, że ONLYOFFICE liczy równoczesnego aktywnego użytkownika jako osobę z otwartym dokumentem, niezależnie od tego, czy edytuje, czy przegląda. Porównaj maksymalną liczbę otwartych edytorów z wymaganiami systemowymi Community Docker dla danej edycji . Podane wartości to konfiguracje referencyjne, a dokumentacja podaje, że rzeczywista pojemność zależy od typu i rozmiaru dokumentu.

2. Jeśli redaktorzy połączą się ponownie, sprawdź serwer proxy i ścieżkę sieciową

Jeśli edytor ładuje się, ale współredaktorzy wielokrotnie się rozłączają lub opóźnienie występuje tylko w publicznym adresie URL, przed dodaniem zasobów serwera należy sprawdzić odwrotny serwer proxy. WebSocket to stałe połączenie używane do obsługi ruchu w edytorze na żywo. Serwer proxy, który zamyka się lub nie aktualizuje tego połączenia, może powodować opóźnienia w edycji lub ponowne połączenia.

Sprawdź dzienniki dostępu i błędów serwera proxy podczas jednej opóźnionej sesji. Upewnij się, że Twoja konfiguracja przekazuje nagłówki HTTP Upgrade i Connection oraz zachowuje oryginalnego hosta i protokół. W przypadku NGINX porównaj swoją konfigurację z oficjalnymi przykładami serwerów proxy ONLYOFFICE ; dokumentacja wyraźnie odwołuje się do przekazywanych nagłówków X-Forwarded-Protoi X-Forwarded-Hostnagłówków. Nie wklejaj przykładowego pliku hurtowego, jeśli terminacja TLS, prefiks ścieżki lub topologia serwera proxy różnią się.

Przeprowadź również test z klienta w tej samej sieci LAN i ze standardowej trasy zdalnej. Jeśli sesja sieci LAN jest responsywna, a trasa publiczna jest powolna, sprawdź opóźnienia serwera proxy, zapory sieciowej, sieci VPN, DNS lub WAN. Jeśli obie trasy mają opóźnienia w tym samym czasie, obciążenie po stronie serwera staje się bardziej prawdopodobne. Narzędzia programistyczne przeglądarek mogą pomóc: powtarzające się rozłączenia WebSocket wskazują na obsługę połączenia, podczas gdy stabilne połączenie z powolną edycją na przeciążonym hoście wskazuje na przepustowość lub obciążenie.

3. Wybierz opcję „Szybki” lub „Ścisły” dla przepływu pracy, a nie jako rozwiązanie problemu z serwerem

ONLYOFFICE oferuje szybką współedycję, która jest domyślna i wyświetla zmiany innych użytkowników w czasie rzeczywistym, oraz ścisłą współedycję, która wstrzymuje zmiany do momentu ich zapisania przez użytkownika. Dokumentacja dotycząca współedycji opisuje różnice w sposobie wyświetlania zmian. Tryb ścisły może być odpowiedni dla zespołów, które preferują przeglądanie i stosowanie zmian partiami; tryb szybki jest naturalnym wyborem, gdy liczy się natychmiastowa, wspólna widoczność.

Zmiana trybów nie naprawia przeciążenia procesora, ograniczenia pamięci ani uszkodzonej trasy WebSocket. Potraktuj tryb jako preferencję współpracy, a następnie porównaj tę samą liczbę plików i użytkowników w każdym trybie tylko wtedy, gdy zespół decyduje, który przepływ pracy jest dla niego odpowiedni. Unikaj prezentowania zmiany trybu jako gwarantowanej poprawy wydajności.

4. Skaluj dopiero po pomiarach określających ciśnienie pojemnościowe

Jeśli występują opóźnienia w dokumentach i u użytkowników, a procesor pozostaje nasycony, pamięć jest ograniczona lub kontenery restartują się, należy najpierw zapewnić serwerowi dokumentów odpowiednie zasoby hosta i sprawdzić, czy limity Dockera nie ograniczają hosta. Następnie należy przeprowadzić ponowny test. Opublikowany dokument referencyjny Community Edition Docker wymienia 4 GB pamięci RAM i wymagania dotyczące pamięci masowej, które różnią się w zależności od liczby jednoczesnych użytkowników; dla ponad 400 jednoczesnych aktywnych użytkowników zaleca wdrożenie klastra i wskazuje na Kubernetes. Należy traktować te dane jako punkt odniesienia w planowaniu, a nie jako obietnicę, że dany serwer obsłuży określone obciążenie.

W przypadku małej instalacji zwiększenie dostępnego procesora lub pamięci jest zazwyczaj prostsze w obsłudze niż rozdzielanie usług między hosty. Aby zapewnić wysoką współbieżność, oddzielne lub klastrowane usługi mogą zapewnić większy zapas mocy, ale dodają zależności sieciowe, konfigurację, monitorowanie i punkty awarii. Aktualny, oficjalny przykład Compose firmy ONLYOFFICE obejmuje kontrolę stanu punktu końcowego serwera dokumentów; należy łączyć stan kontenera i responsywność aplikacji, zamiast zakładać, że działający kontener oznacza poprawną ścieżkę edycji. Należy zachować przypiętą wersję obrazu podczas diagnostyki, aby aktualizacja wdrożenia nie zakłócała ​​pomiarów przed i po.

Zweryfikuj poprawkę za pomocą tego samego testu edycji

Powtórz oryginalną edycję dla dwóch użytkowników, używając tego samego dokumentu, ścieżki klienta i przybliżonego obciążenia. Upewnij się, że obaj redaktorzy reagują na pisanie, zmiany pojawiają się spójnie w wybranym trybie współedycji, a ponowne połączenia lub restarty kontenerów zostały zatrzymane. Obserwuj działanie docker statspodczas ponownego testu i sprawdź logi proxy, czy problem był związany z połączeniem. Jeśli krótki test działa, ale sesje w godzinach szczytu nadal występują opóźnienia, zbierz obraz/wersję kontenera, wersje hosta i Dockera, zamontowane woluminy, wykresy zasobów i odpowiednie logi przed zmianą dalszych ustawień; oficjalny przewodnik po rejestrowaniu debugowania wyjaśnia, jak włączyć tymczasowe logi debugowania w Dockerze. Po zebraniu dowodów wyłącz rejestrowanie szczegółowe, ponieważ zwiększa ono wolumen logów.

Na podstawie wyniku wybierz kompromis: popraw serwer proxy, gdy połączenia zostaną zerwane, zwiększ pojemność, gdy pomiary wykażą stałe obciążenie zasobów, i pozostaw serwer w spokoju, gdy problem dotyczy tylko jednego złożonego dokumentu, dopóki nie wyizolujesz tego obciążenia.