Dlaczego WordPress nie utrzyma websocketu i co zrobić zamiast tego

Prędzej czy później witryna WordPress potrzebuje czegoś, co dzieje się na żywo: nowej wiadomości, która pojawia się bez przeładowania strony, powiadomienia w chwili, gdy wpada zamówienie, licznika osób online, rozmowy, która dzwoni. W sieci służy do tego websocket, czyli połączenie między przeglądarką a serwerem, które pozostaje otwarte, dzięki czemu serwer może wysłać dane w chwili, gdy coś się wydarzy.

I wtedy przychodzi niespodzianka: WordPress nie ma serwera WebSocket, a hosting, na którym działa, nie jest w stanie go utrzymać. Ten wpis wyjaśnia dlaczego, co zwykle robią z tym witryny i ile kosztuje utrzymanie własnego serwera WebSocket.

WordPress odpowiada na żądanie i kończy pracę

Każda strona WordPress, każde wywołanie REST API i każde żądanie admin-ajax działa tak samo. Serwer WWW przekazuje żądanie do PHP, PHP ładuje WordPress z jego wtyczkami i motywem, przygotowuje odpowiedź, wysyła ją i kończy pracę. Następne żądanie znów zaczyna od zera.

Dzięki temu modelowi WordPress działa prawie wszędzie. Przez ten sam model nie może utrzymać websocketu. Websocket to nie jedno żądanie, ale połączenie, które pozostaje otwarte tak długo, jak otwarta jest strona, często godzinami. Utrzymanie go wymagałoby procesu PHP dla każdej otwartej strony, który przez większość czasu nic nie robi, a hosting daje witrynie tylko niewielką liczbę procesów PHP, wystarczającą na żądania kończące się w ułamku sekundy. Garstka odwiedzających z otwartą stroną zajęłaby je wszystkie i witryna przestałaby odpowiadać wszystkim pozostałym.

Firmy hostingowe chronią się przed tym. Przerywają żądania, które trwają zbyt długo, często po 30–60 sekundach, a w większości planów nie pozwalają witrynie uruchomić własnego procesu w tle ani otworzyć dla niego portu. Nawet tam, gdzie hosting na to pozwala, serwer przed PHP i każde proxy przed tym serwerem muszą być skonfigurowane tak, żeby przepuszczały websocket.

Polling: pytanie raz po raz

Zwykle obchodzi się to pollingiem. Strona co kilka sekund pyta serwer: „czy jest coś nowego?”. Zwykle odpowiedź brzmi: nie.

Każde z tych pytań to pełne żądanie WordPress: PHP się uruchamia, ładuje WordPress i wtyczki, odpytuje bazę danych i odpowiada. Przy 50 odwiedzających na stronie, która pyta co 5 sekund, daje to 10 pełnych żądań WordPress na sekundę, w każdej sekundzie, przez większość czasu na nic. Pytaj rzadziej, a witryna wydaje się powolna, bo wiadomość pojawia się dopiero po pół minuty. Pytaj częściej, a hosting zaczyna mieć problemy albo przysyła ostrzeżenie o zużyciu zasobów.

WordPress ma własną wersję tego mechanizmu, Heartbeat API, które pyta co 15 do 60 sekund. Sprawdza się przy zapisywaniu szkiców i pokazywaniu, kto edytuje wpis. Dla czatu czy rozmowy jest o wiele za wolne.

Long polling i server-sent events, w których serwer trzyma żądanie otwarte, dopóki coś się nie wydarzy, wyglądają na rozwiązanie. Na WordPress nim nie są: każde czekające żądanie zajmuje proces PHP, więc trafiają prosto na to samo ograniczenie co websocket.

Własny serwer WebSocket

Prawdziwym rozwiązaniem jest serwer zbudowany do utrzymywania wielu otwartych połączeń, działający obok WordPress, a nie w nim. Wiele zespołów taki buduje. Czego to wymaga:

• Własnego serwera, zwykle małego serwera wirtualnego z Node.js albo innym środowiskiem uruchomieniowym stworzonym do długich połączeń, z własnymi aktualizacjami i monitorowaniem.
• Certyfikatu i proxy, żeby przeglądarka mogła łączyć się przez wss:// w Twojej domenie.
• Znajomości Twoich użytkowników. Serwer WebSocket nie wie, kto jest zalogowany w WordPress, więc Twoja witryna musi dać każdej stronie podpisany token, a serwer musi go sprawdzić i zdecydować, kto może dołączyć do którego kanału.
• Sposobu, żeby WordPress mógł wysyłać. Gdy coś dzieje się w WordPress, hook musi powiadomić serwer WebSocket, który wysyła to dalej do właściwych przeglądarek.
• Więcej niż jednego, w miarę wzrostu. Jeden serwer to jedno miejsce, w którym mogą zerwać się wszystkie połączenia. Dwa lub więcej potrzebują sposobu na wymianę wiadomości między sobą, a strony muszą płynnie łączyć się ponownie, gdy serwer się restartuje.

Nic z tego nie jest egzotyczne, ale to drugi system, który trzeba utrzymywać obok WordPress tak długo, jak witryna ma funkcje na żywo. Dla rozmów to dopiero początek: rozmowa potrzebuje też serwerów STUN i TURN, a rozmowy grupowe serwerów mediów, jak wyjaśnia nasz wpis o tym, jak działają grupowe rozmowy wideo.

Albo niech połączenia utrzymuje chmura czasu rzeczywistego

Drugim sposobem jest hostowana usługa czasu rzeczywistego. Przeglądarki utrzymują otwarte połączenia z usługą, a nie z Twoim hostingiem. Gdy na Twojej witrynie coś się dzieje, WordPress wysyła do usługi jedno krótkie żądanie, a usługa dostarcza zdarzenie do każdej strony, która powinna je dostać. Twój hosting odpowiada tylko na zwykłe żądania, tak jak zawsze.

WordPress pozostaje miejscem, w którym są Twoje dane. Usługa tylko przenosi zdarzenia z witryny do stron i między stronami, więc nic się nie zmienia w tym, jak Twoja witryna przechowuje wpisy, użytkowników czy zamówienia.

Jak WordPlus Cloud robi to dla WordPress

WordPlus Cloud for WordPress to właśnie taka chmura, dla każdej wtyczki na witrynie WordPress:

• Nic do utrzymania. Serwery czasu rzeczywistego, przekaźniki rozmów, serwery mediów i AI działają w chmurze. Twoja witryna potrzebuje tylko subskrypcji, z ceną za witrynę, bez limitu użytkowników i wiadomości.
• Może z niej korzystać każda wtyczka na witrynie. Better Messages i Live Stream korzystają z niej od razu. Wtyczki stworzone dla protokołu Pusher łączą się przez nasze hosty i klucze Twojej witryny, a każda inna wtyczka, motyw czy własny kod łączy się przez nasze API dla deweloperów.
• Dane zostają na Twojej witrynie WordPress. Rozmowy, użytkownicy i pliki zostają w Twojej bazie danych. Wiadomości przechodzą przez chmurę zapieczętowane kluczem, który przechowuje Twoja witryna, więc przekazujemy je bez odczytywania.
• Więcej niż websockety. Ta sama subskrypcja daje rozmowy, które zawsze się łączą, rozmowy grupowe, powiadomienia push w przeglądarkach i na telefonach, transmisje na żywo, Twoje własne aplikacje mobilne i AI, przez to samo połączenie.

Strona utrzymuje jedno połączenie, wspólne dla wszystkich wtyczek na witrynie, które przechodzi na inny serwer bez zerwania, gdy któryś się restartuje. Twój hosting wraca do tego, co robi dobrze: odpowiadania na żądania.

Zobacz WordPlus Cloud for WordPress albo cennik dla tylu witryn, ilu potrzebujesz.