Как избежать катастрофы CMS: как предотвратить простои сайта

Что на самом деле означает, что сайт считается неработающим ?

Часто это зависит от того, кого вы спрашиваете.

Для веб-сайта, который считается неработающим, это может означать несколько разных вещей:

• Сайт полностью недоступен.
• Сайт онлайн, но неприемлемо медленный.
• Веб-сайт выдает сообщения об ошибках для определенных пользователей или местоположений.
• Веб-сайт работает для большинства посетителей, но некоторые просто не могут войти в свою CMS, например, для создания, редактирования или публикации контента.

Независимо от причины или степени, последствия простоя веб-сайта могут быть серьезными: от потерянных заказов электронной торговли и разочарования пользователей до ослабления доверия клиентов.

В третьей части нашей серии «Как избежать катастрофы с CMS » мы исследуем классические первопричины простоя веб-сайта и роль непрерывного мониторинга и других факторов в предотвращении этого.

Во-первых, роль непрерывного мониторинга

Мы отслеживаем различные аспекты веб-сайта, поэтому мы можем определить, когда что-то работает неправильно на любом из различных уровней, составляющих нашу полностью управляемую VIP-платформу WordPress. Эти слои включают в себя:

• Сетевое подключение
• Балансировщики нагрузки
• Веб-серверы
• Кэширование объектов (Memcached)
• Базы данных
• Эластичный поиск
• Файловая служба (CDN)

Мы стараемся выявлять проблемы на ранней стадии, чтобы мы могли предвидеть будущие проблемы, которые могут повлиять на стабильность веб-сайта. Перекрестные ссылки в журналах различных системных компонентов позволяют нам просматривать периоды, когда веб-сайт сообщался о нестабильной работе. Поскольку причиной простоя может быть сочетание факторов, а не одна проблема, мы используем ряд инструментов для сравнения данных как по системам, так и по приложениям.

В большинстве случаев нестабильность веб-сайта является результатом кода приложения, т. е. пользовательской или сторонней темы WordPress и кода плагина. Вот несколько вещей, на которые мы обращаем внимание при исследовании нестабильного сайта, и способы их устранения.

Недостаточно кэширования

Самое важное, что вы можете сделать для обеспечения производительности и стабильности сайта, — это обеспечить кэширование любой полной страницы, которая может быть кэширована. Некэшированные страницы необходимо создавать на сервере каждый раз, когда они запрашиваются, что является более медленным процессом и более подвержено ошибкам.

VIP-ответ WordPress:

WordPress VIP Platform обеспечивает мощное кэширование страниц через глобальную сеть пограничных кэш-серверов, каждый из которых используется для хранения и обслуживания контента, наиболее близкого к конечному пользователю. Время отклика от пограничного кэш-сервера почти всегда на порядок меньше, чем у всего, что обходит кэширование страниц и обращается к исходным серверам.

Проблемы с кэшированием

Поскольку они требуют персонализированного, полностью интерактивного опыта, некоторые сайты, особенно сайты электронной коммерции, просто не могут кэшироваться на уровне кэша страниц.

Часто можно найти компромисс, когда статическая страница обслуживается пограничным кешем, а динамические функции (например, статус входа в систему, корзины покупок) добавляются через JavaScript. Затем асинхронные запросы из JavaScript можно использовать для связи с конечной точкой WordPress REST API, спроектированной с гораздо меньшими накладными расходами, чем полная загрузка страницы.

В качестве альтернативы, здесь в игру вступает кэширование объектов. Страница может оставаться динамической, но части страницы и любые данные, используемые на ней, могут храниться и извлекаться в кэше объектов, чтобы избежать необходимости запрашивать базу данных.

VIP-ответ WordPress:

Каждая среда приложений WordPress VIP имеет свой собственный выделенный кластер Memcached, который хранит данные кэша объектов в памяти для молниеносного и эффективного извлечения.

Развертывание непроверенного кода

Это еще одна распространенная причина простоя веб-сайта, которую довольно легко диагностировать, основываясь на чистой причине и следствии.

Если на вашем веб-сайте только что был развернут непроверенный код, что привело к немедленным проблемам с сайтом, вероятно, причина в этом. Если можете, верните подозрительный код к предыдущей версии как можно скорее.

Что лучше сделать, чтобы избежать этой ситуации? Тщательно тестируйте каждый фрагмент кода в отдельной среде разработки или промежуточной среде перед выпуском в рабочую среду.

VIP-ответ WordPress:

Поскольку все наши сайты развертываются через GitHub, VIP-клиенты WordPress могут легко отменить код самостоятельно, не теряя никаких новых изменений кода, которые надежно хранятся в истории изменений GitHub. При желании в экстренных ситуациях мы можем откатить веб-сайт клиента до предыдущего развертывания от его имени, независимо от GitHub.

Что касается сред, все приложения, размещенные в нашем полностью управляемом сервисе, могут иметь отдельную среду разработки или промежуточную среду. Синхронизировать данные из рабочей среды очень просто, что позволяет вам тестировать код с тем же объемом и тем же типом данных, что и на вашем рабочем веб-сайте.

PHP-ошибки

WordPress использует PHP-код на сервере. Ошибка PHP может быть «фатальной», что означает, что после ее возникновения веб-страница, скрипт или команда перестанут работать. Они почти всегда будут отображаться как видимые ошибки где-то и будут записаны в журналах PHP.

Примечание. Некоторые предупреждения PHP в PHP 7 становятся фатальными ошибками в PHP 8, поэтому важно относиться к этим ошибкам серьезно.

VIP-ответ WordPress (плюс полезный совет):

Наша платформа автоматически регистрирует все ошибки PHP, делая их доступными для VIP-клиентов WordPress в их панели управления и для наших инженеров.

Совет для профессионалов : исправляйте все ошибки PHP, даже если кажется, что сайт работает нормально. Обычно мы видим журналы, полные ошибок PHP, даже фатальных, на сайте, который кажется стабильным. Однако это не обязательно означает, что сайт работает правильно . Поддержание чистоты журналов PHP путем устранения незначительных ошибок и предупреждений облегчает поиск более серьезных ошибок во время отладки.

Медленные запросы к базе данных MySQL

Каждый веб-сайт WordPress использует базу данных для хранения содержимого веб-сайта и данных конфигурации. Запросы к базе данных извлекают эти данные содержимого для веб-страниц, но иногда эти запросы написаны неэффективно. Они могут нормально работать для сайтов, содержащих всего несколько сотен страниц, но зависать при обработке больших объемов данных (некоторые веб-сайты на нашей платформе хранят миллионы записей).

Медленный запрос связывает ресурсы базы данных, потенциально влияя на стабильность сайта — не только для страницы, скрипта или команды, выполняющей SQL, но и для всего приложения. Сайты часто испытывают трудности, потому что один или несколько запросов к базе данных выполняются медленно, например любой запрос, выполнение которого занимает более 0,75 секунды.

VIP-ответ WordPress:

WordPress VIP помогает устранить узкие места в базе данных, предоставляя каждому приложению выделенный кластер базы данных с основной базой данных, в которой происходят все запросы на запись в базу данных, и одной или несколькими базами данных-репликами, доступными только для чтения. Это увеличивает количество одновременных запросов к базе данных, которые могут выполняться, распределяя нагрузку на ресурсы, когда сайт находится под нагрузкой. Тем не менее, медленные запросы к базе данных не всегда могут быть решены простым добавлением дополнительных ресурсов базы данных. Вот почему мы советуем клиентам отслеживать медленные запросы к базе данных с помощью Query Monitor и New Relic (предоставляемых нашей платформой). Они подсвечивают, где в базе данных возникают запросы, поэтому ваша команда разработчиков может реорганизовать их для оптимизации производительности.

Наконец, наша служба поддержки приложений и ведущие инженеры также могут помочь вашей команде найти и проанализировать эти запросы и предложить способы их улучшения для повышения скорости и эффективности.

Чрезмерная запись в базу данных

Иногда функция, например пользовательское ведение журнала или код отслеживания, обновляет базу данных при каждом запросе. Это может привести к нестабильности по двум причинам:

• Вышеуказанные реплики базы данных : все запросы на запись направляются в первичную базу данных; последующие запросы к базе данных для той же таблицы (или таблиц) в том же запросе страницы также будут направлены туда. Отсутствие использования реплик базы данных ограничивает масштабируемость сайта.
• Обход кэширования страниц : чтобы запись в базу данных происходила при каждом запросе страницы, кэширование страниц должно быть обойдено. Но это означает, что первая (и лучшая) линия защиты была скомпрометирована.

VIP-ответ WordPress:

В этих обстоятельствах мы советуем провести рефакторинг этой функции. Например, аналитику контента обычно лучше делегировать внешней службе, которая использует фрагмент кода JavaScript на странице, а не код на стороне сервера, который плохо работает с кэшированием и может привести к избыточным операциям записи в базу данных.

Другие известные причины простоя и как их избежать

Плагины

В экосистеме WordPress есть тысячи популярных и полезных сторонних плагинов, которые обеспечивают фантастические возможности и функциональность. У некоторых, тем не менее, есть проблемы с масштабированием, что может привести к проблемам с простоем при добавлении на веб-сайт с огромным количеством контента и трафика.

VIP-ответ WordPress:

Как хорошие управляющие экосистемой, мы регулярно обращаемся к поставщикам с предложениями, как улучшить работу их плагинов в средах с высоким трафиком. Мы также можем предложить альтернативные плагины, которые были опробованы и протестированы на нашей платформе.

Пользовательское ведение журнала

Пользовательское ведение журналов — это мощный инструмент отладки, часто единственный действенный метод для отслеживания ошибок или проблем, которые, по-видимому, возникают только на рабочем сайте. Однако во многих случаях мы видели, как пользовательское ведение журнала, встроенное в PHP, на сайте с высоким трафиком замедляло работу или подвергало сайт риску простоя из-за чрезмерных операций записи в базу данных.

VIP-ответ WordPress:

Для клиентов мы предоставляем доступ к стандартным логам PHP на панели Health панели WordPress VIP Application Dashboard. Там они могут логировать пользовательские ошибки (а также в New Relic), что не окажет негативного влияния на базу данных.

Удаленные вызовы API

Некоторые веб-сайты используют вызовы API REST на стороне сервера для других приложений или служб. В нормальных условиях они работают довольно быстро, но иногда базовый код приложения приводит к медленному отклику, тайм-ауту или выдает ошибку.

VIP-ответ WordPress:

Чтобы свести к минимуму эти проблемы, мы рекомендуем «защитное кодирование». Это зависит от цели удаленного вызова, но часто, когда удаленный запрос терпит неудачу, можно вернуться к закэшированному ответу предыдущего запроса или, по крайней мере, «изящно обработать ошибку», чтобы остальная часть страницы могла еще загрузить. Мы предоставляем ряд вспомогательных функций для обработки этих сценариев. Поддержание низкого времени ожидания также означает, что ресурсы PHP освобождаются быстрее, если удаленный API не отвечает.

Подробнее читайте в нашей серии «Как избежать катастрофы с CMS»

Когда ваш бизнес находится под угрозой, вы не можете позволить себе отправить новый бизнес в другое место и запятнать свой бренд, если ваша система управления контентом (CMS) будет плохо работать с цифровыми технологиями. В разделе «Как повысить производительность веб-сайта» мы диагностируем пять распространенных причин замедления работы и способы ускорения работы с помощью гибкой CMS.

Дни с интенсивным трафиком должны быть поводом для праздника, а не кошмаром для инженеров, которые в коллективе отстают, пытаясь поддерживать сайт и приложения в рабочем состоянии и напевая, чтобы справиться с нагрузкой — и ваша репутация не пострадала. В разделе «Масштабирование WordPress для высокого трафика » мы рассмотрим четыре подхода к тому, чтобы веб-сайт WordPress мог справляться с этими приливными волнами трафика.