Хостинг Пульс

"Хостинг Пульс" - сервис, позволяющий сравнить производительность хостинг провайдеров и выбрать хороший хостинг.

На одном из серверов, каждого тестируемого хостинга, размещается сайт, собирающий статистику производительности.

Дневные результаты передаются сервису "Хостинг Пульс", который обрабатывает данные, присваивает рекорды, рейтинги и формирует страницы отчетов.

Цель проекта - прозрачный технический обзор производительности хостинг провайдеров и помощь в выборе хостинга.

Требования к хостингу довольно простые - он должен работать (отказоустойчивость) и оперативно обрабатывать запросы (производительность).

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

Google PageSpeed Insights выдает предупреждение "Оптимизируйте время ответа сервера", если страница сайта формируется дольше 200 мс.

Рассмотрим подробнее, что же происходит на сервере, когда кто-то запрашивает страницу ресурса.

Для каждой операции указаны используемые показатели производительности (чем лучше, тем быстрее выполнится операция) и степень типовой нагрузки.

Загрузка ядра сайта, всех модулей и плагинов.

• Загрузка скриптов
  • Скорость чтения файлов легкая нагрузка
• Загрузка настроек
  • Скорость чтения и производительность базы данных легкая нагрузка
• Выполнение скриптов
  • Вычислительная мощность сервера возможна тяжелая нагрузка зависит от количества модулей и плагинов.

Если используется кэширование

• Проверить, есть ли сохраненная копия страницы
  • Скорость чтения и производительность базы данных легкая нагрузка

Если запрашиваемая страница есть в кэше

• Загрузить сохраненную копию страницы
  • Вычислительная мощность сервера легкая нагрузка
  • Скорость чтения базы данных или файлов (в зависимости от хранилища кэша) легкая нагрузка

Если страницы нет в кэше или кэширование не используется

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

Если используется кэширование и запрашиваемой страницы нет в кэше

• Сохранить получившуюся страницу в кэше
  • Скорость записи базы данных или файлов (в зависимости от хранилища кэша) легкая нагрузка

Как только страница сформирована

• Отправить данные пользователю
  • Сеть возможна тяжелая нагрузка зависит от структуры страницы.

Если не вдаваться в детали, все получается не так сложно и становится понятно, на какие параметры хостинга стоит обращать внимание в первую очередь.

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

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

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

  Плохая новость - доказать тут что-то вряд ли получится и история больше очередная "страшная сказка", как и оверселлинг, в которую кто-то верит, а кто-то нет.

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

• Накопитель информации (диск) задействован при любом запросе. Даже страницу статического сайта надо "прочитать" с диска прежде, чем отправить пользователю. Чем выше скорость чтения информации с диска, тем меньше времени понадобится серверу для загрузки скриптов, шаблонов, изображений и т.д.

• Большинство сайтов - динамические и это значит что процессор сервера и база данных будут использоваться активно. Системы управления контентом (CMS), чаще всего, хранят созданные пользователем материалы (новости, статьи, товары и т.д.) именно в базе данных. Чем выше производительность и скорость чтения базы данных, тем быстрее сервер сможет загрузить материалы. Процессор, в основном, используется для загрузки ядра, модулей, плагинов и адаптации материалов к шаблонам.

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

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

• На сколько важно качество сетевых подключений - решать Вам. Для проверки внешних соединений используются показатели "Задержка соединения - Google" и "Задержка соединения - Yandex".

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

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

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

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

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