Unikanie katastrofy CMS: jak zapobiegać przestojom witryny?

Co to właściwie oznacza, że ​​witryna została uznana za niedziałającą ?

Często zależy to od tego, kogo zapytasz.

Aby strona internetowa została uznana za niedziałającą, może to oznaczać kilka różnych rzeczy:

• Strona jest całkowicie niedostępna.
• Witryna jest online, ale bezużytecznie powolna.
• Witryna wyświetla komunikaty o błędach dla określonych użytkowników lub lokalizacji.
• Witryna działa dla większości odwiedzających, ale niektórzy po prostu nie mogą zalogować się do swojego systemu CMS, na przykład w celu tworzenia, edytowania lub publikowania treści.

Bez względu na przyczynę lub stopień, wpływ przestojów w witrynie może być poważny, od utraconych zamówień e-commerce i sfrustrowanych użytkowników po osłabione zaufanie klientów.

W trzeciej części naszej serii Unikanie katastrofy CMS badamy klasyczne przyczyny przestojów witryny oraz rolę ciągłego monitorowania i innych czynników w unikaniu tego.

Po pierwsze, rolę odgrywa ciągłe monitorowanie

Monitorujemy różne aspekty strony internetowej, dzięki czemu możemy stwierdzić, kiedy coś nie działa poprawnie na którejkolwiek z różnych warstw, które tworzą naszą w pełni zarządzaną platformę VIP WordPress. Warstwy te obejmują:

• Łączność sieciowa
• Systemy równoważenia obciążenia
• Serwery WWW
• Buforowanie obiektów (Memcached)
• Bazy danych
• Elastyczne wyszukiwanie
• Usługa plików (CDN)

Staramy się wcześnie wykrywać problemy, aby móc przewidzieć przyszłe problemy, które mogą wpłynąć na stabilność witryny. Odsyłanie logów z różnych komponentów systemu pozwala nam przejrzeć okresy, w których strona była zgłaszana jako niestabilna. Ponieważ za przestoje może odpowiadać kombinacja czynników, a nie jeden problem, stosujemy szereg narzędzi do porównywania danych zarówno w systemach, jak i aplikacjach.

W większości przypadków niestabilność witryny jest wynikiem kodu aplikacji, tj. niestandardowego lub pochodzącego od strony trzeciej motywu WordPress i kodu wtyczki. Oto kilka rzeczy, na które zwracamy uwagę, badając niestabilną witrynę, oraz sposoby ich łagodzenia.

Za mało pamięci podręcznej

Najważniejszą rzeczą, jaką możesz zrobić, aby witryna była wydajna i stabilna, jest upewnienie się, że każda pełna strona, którą można zapisać w pamięci podręcznej, jest zbuforowana. Strony bez pamięci podręcznej muszą być budowane na serwerze za każdym razem, gdy są żądane, co jest procesem wolniejszym i bardziej podatnym na błędy.

Odpowiedź VIP WordPressa:

Platforma VIP WordPress zapewnia potężne buforowanie stron za pośrednictwem globalnej sieci brzegowych serwerów pamięci podręcznej, z których każdy służy do przechowywania i udostępniania treści najbliżej użytkownika końcowego. Czas odpowiedzi z serwera brzegowej pamięci podręcznej jest prawie zawsze o wiele szybszy niż wszystko, co omija buforowanie stron i trafia na serwery pochodzenia.

Wyzwania buforowania

Ponieważ wymagają one spersonalizowanego, w pełni interaktywnego doświadczenia, niektórych witryn, zwłaszcza witryn e-commerce, po prostu nie można buforować na poziomie pamięci podręcznej strony.

Często można znaleźć kompromis polegający na tym, że strona statyczna jest obsługiwana przez pamięć podręczną krawędzi, z dynamicznymi funkcjami (np. status zalogowania, koszyki) dodanymi przez JavaScript. Żądania asynchroniczne z JavaScript mogą być następnie wykorzystywane do komunikacji z punktem końcowym interfejsu API REST WordPress, zaprojektowanym ze znacznie mniejszym obciążeniem niż pełne ładowanie strony.

Alternatywnie, w tym miejscu w grę wchodzi buforowanie obiektów. Strona może pozostać dynamiczna, ale części strony i wszelkie używane w niej dane mogą być przechowywane i pobierane w pamięci podręcznej obiektów, aby uniknąć konieczności wykonywania zapytań do bazy danych.

Odpowiedź VIP WordPressa:

Każde środowisko aplikacji WordPress VIP ma własny dedykowany klaster Memcached, który przechowuje dane z pamięci podręcznej obiektów w pamięci w celu błyskawicznego i wydajnego wyszukiwania.

Nieprzetestowane wdrożenia kodu

Jest to kolejny częsty winowajca przestojów w witrynie i dość łatwy do zdiagnozowania, w oparciu o czystą przyczynę i skutek.

Jeśli Twoja witryna właśnie wdrożyła nieprzetestowany kod, co prowadzi do natychmiastowych problemów z witryną, istnieje prawdopodobna przyczyna. Jeśli możesz, jak najszybciej przywróć podejrzany kod do poprzedniej wersji.

Co zrobić, aby uniknąć takiej sytuacji? Dokładnie przetestuj każdy fragment kodu w osobnym środowisku programistycznym lub przejściowym przed wydaniem go do produkcji.

Odpowiedź VIP WordPressa:

Ponieważ wszystkie wdrożenia naszych witryn odbywają się za pośrednictwem GitHub, klienci VIP WordPress mogą łatwo przywrócić kod samodzielnie, bez utraty nowych zmian w kodzie, które pozostają bezpiecznie przechowywane w historii wersji GitHub. Opcjonalnie w sytuacjach awaryjnych, niezależnie od GitHub, możemy przywrócić stronę klienta do poprzedniego wdrożenia w jego imieniu.

Jeśli chodzi o środowiska, wszystkie aplikacje hostowane w naszej w pełni zarządzanej usłudze mogą mieć oddzielne środowisko programistyczne lub tymczasowe. Synchronizowanie tam danych z produkcji jest łatwe, co pozwala przetestować kod na tej samej ilości i tym samym typie danych, co w witrynie produkcyjnej.

Błędy PHP

WordPress używa kodu PHP na serwerze. Błąd PHP może być „krytyczny”, co oznacza, że ​​po wystąpieniu błędu strona internetowa, skrypt lub polecenie przestaną działać. Te prawie zawsze pojawią się gdzieś jako widoczne błędy i zostaną zapisane w dziennikach PHP.

Uwaga: Niektóre ostrzeżenia PHP w PHP 7 stają się błędami krytycznymi w PHP 8, więc ważne jest, aby traktować te błędy poważnie.

Odpowiedź VIP WordPress (plus pomocna rada):

Nasza platforma automatycznie rejestruje wszystkie błędy PHP, udostępniając je klientom VIP WordPress na ich pulpicie nawigacyjnym oraz naszym inżynierom.

Wskazówka dla profesjonalistów: Rozwiąż i napraw wszystkie błędy PHP — nawet jeśli witryna wydaje się działać poprawnie. Rutynowo widzimy logi pełne błędów PHP, nawet tych krytycznych, na stronie, która wydaje się stabilna. Nie musi to jednak oznaczać, że witryna działa poprawnie . Utrzymywanie przejrzystych dzienników PHP poprzez usuwanie drobnych błędów i ostrzeżeń ułatwia znajdowanie poważniejszych błędów podczas debugowania.

Powolne zapytania do bazy danych MySQL

Każda witryna WordPress korzysta z bazy danych do przechowywania treści witryny i danych konfiguracyjnych. Zapytania do bazy danych pobierają dane dotyczące treści stron internetowych, ale czasami te zapytania są zapisywane nieefektywnie. Mogą działać dobrze w przypadku witryn zawierających tylko kilkaset stron, ale zatrzymują się podczas obsługi dużych ilości danych (niektóre witryny na naszej platformie mają miliony zapisanych rekordów).

Powolne zapytanie blokuje zasoby bazy danych, potencjalnie wpływając na stabilność witryny — nie tylko w przypadku strony, skryptu lub polecenia uruchamiającego SQL, ale w całej aplikacji. Witryny często mają problemy, ponieważ pojedyncze lub wiele zapytań do bazy danych jest powolnych, np. każde zapytanie, którego wykonanie trwa dłużej niż 0,75 sekundy.

Odpowiedź VIP WordPressa:

WordPress VIP pomaga złagodzić wąskie gardła bazy danych, zapewniając każdej aplikacji dedykowany klaster bazy danych zawierający podstawową bazę danych, w której występują wszystkie zapytania dotyczące zapisu bazy danych, oraz jedną lub więcej baz danych z replikami tylko do odczytu. Zwiększa to liczbę jednoczesnych zapytań do bazy danych, które mogą mieć miejsce, rozkładając obciążenie zasobów, gdy witryna jest pod presją. To powiedziawszy, powolne zapytania do bazy danych nie zawsze mogą być rozwiązane po prostu przez dodanie dodatkowych zasobów bazy danych. Dlatego zalecamy klientom monitorowanie powolnych zapytań do bazy danych za pomocą Query Monitor i New Relic (dostarczanych przez naszą platformę). Podkreślają one, skąd pochodzą zapytania w bazie danych, dzięki czemu zespół programistów może je refaktoryzować, aby zoptymalizować wydajność.

Wreszcie, nasze wsparcie aplikacji i inżynierowie Premier mogą również pomóc Twojemu zespołowi znaleźć i przeanalizować te zapytania oraz zasugerować sposoby ich ulepszenia pod kątem szybkości i wydajności.

Nadmierna liczba zapisów w bazie danych

Czasami funkcja, taka jak niestandardowe logowanie lub kod śledzenia, aktualizuje bazę danych na każde żądanie. Może to prowadzić do niestabilności z dwóch powodów:

• Wyżej wymienione repliki bazy danych : Wszystkie zapytania dotyczące zapisu są kierowane do podstawowej bazy danych; Kolejne zapytania bazy danych o tę samą tabelę (lub tabele) w tym samym żądaniu strony również będą tam kierowane. Nie korzystając z replik baz danych, ogranicza to skalowalność witryny.
• Pomijanie pamięci podręcznej strony : aby zapisywanie w bazie danych odbywało się przy każdym żądaniu strony, należy pominąć pamięć podręczną strony. Ale to oznacza, że ​​pierwsza (i najlepsza) linia obrony została skompromitowana.

Odpowiedź VIP WordPressa:

W takich okolicznościach zalecamy refaktoryzację funkcji. Na przykład analiza treści jest zwykle najlepiej delegowana do usługi zewnętrznej, która używa fragmentu kodu JavaScript na stronie, a nie kodu po stronie serwera, co nie działa dobrze z buforowaniem i może skutkować nadmiernymi zapisami w bazie danych.

Inne znane przyczyny przestojów i sposoby ich unikania

Wtyczki

W ekosystemie WordPressa znajdują się tysiące popularnych, pomocnych wtyczek innych firm, które zapewniają fantastyczne funkcje i funkcjonalność. Niektóre jednak mają problemy ze skalowaniem, które mogą prowadzić do problemów z przestojami po dodaniu do witryny z mnóstwem treści i ruchu.

Odpowiedź VIP WordPressa:

Jako dobrzy zarządcy ekosystemów regularnie kontaktujemy się z dostawcami z sugestiami, aby ich wtyczki działały lepiej w środowiskach o dużym natężeniu ruchu. Możemy również zaproponować alternatywne wtyczki, które zostały wypróbowane i przetestowane na dużą skalę na naszej platformie.

Rejestrowanie niestandardowe

Rejestrowanie niestandardowe to potężne narzędzie do debugowania, często jedyna realna metoda śledzenia błędu lub problemu, który wydaje się występować tylko w witrynie produkcyjnej. Jednak w wielu przypadkach widzieliśmy niestandardowe rejestrowanie wbudowane w PHP w witrynie o dużym natężeniu ruchu, która spowalnia działanie lub naraża witrynę na niebezpieczeństwo przestoju z powodu nadmiernego zapisu w bazie danych.

Odpowiedź VIP WordPressa:

Klientom zapewniamy dostęp do standardowych logów PHP w panelu Zdrowie panelu aplikacji WordPress VIP. Tam mogą rejestrować niestandardowe błędy (a także w New Relic), co nie wpłynie negatywnie na bazę danych.

Zdalne wywołania API

Niektóre witryny wykorzystują wywołania API REST po stronie serwera do innych aplikacji lub usług. W normalnych warunkach są one dość szybkie, ale czasami kod aplikacji powoduje powolną odpowiedź, przekroczenie limitu czasu lub wygeneruje błąd.

Odpowiedź VIP WordPressa:

Aby zminimalizować te problemy, zalecamy „kodowanie obronne”. Zależy to od celu wywołania zdalnego, ale często, gdy zdalne żądanie nie powiedzie się, można skorzystać z buforowanej odpowiedzi z poprzedniego żądania — lub przynajmniej „wdzięcznie obsłużyć błąd”, aby reszta strony mogła nadal się ładuje. Udostępniamy szereg funkcji pomocniczych do obsługi tych scenariuszy. Utrzymanie niskiego limitu czasu oznacza również, że zasoby PHP są zwalniane szybciej, jeśli zdalny interfejs API nie odpowiada.

Przeczytaj więcej w naszej serii Unikanie katastrofy CMS

Kiedy Twoja firma jest na linii, nie możesz pozwolić sobie na wysyłanie nowych firm gdzie indziej i niszczenie marki, ponieważ Twój system zarządzania treścią (CMS) zapewnia słabe wrażenia cyfrowe. W artykule Jak poprawić wydajność witryny , diagnozujemy pięciu najczęstszych winowajców spowolnienia i jak turbodoładować rzeczy za pomocą zwinnego CMS.

Dni o dużym natężeniu ruchu powinny być powodem do świętowania, a nie koszmarem dla inżynierów, którzy próbują utrzymać witrynę i aplikacje w ruchu, aby poradzić sobie z obciążeniem — i nienaruszoną reputacją. W Skalowaniu WordPressa pod kątem dużego ruchu analizujemy cztery podejścia do umożliwienia witrynie opartej na WordPressie radzenia sobie z tymi falami ruchu.