Документация

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

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

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

Отказоустойчивость

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

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

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

Популярность

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

Задержка сервера

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

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

connect_time - время получения первого байта ответа сервера на запрос соединения.
pretransfer_time - время окончания согласования протоколов. Практически равен connect_time при отсутствии ssl т.к. завершается при прочтении пакета начатого в connect_time. Не включает в себя время на отправку пакета о запросе данных.
starttransfer_time - время получения первого байта данных.

Исходя из данных значений можно вычислить RTT (круговое время задержки соединения) = connect_time - namelookup_time т.к. в данный промежуток отправляется ровно один пакет из цепочки handshake TCP и принимается первый байт данных ответа сервера.
Зная RTT можно посчитать "серверное время" = starttransfer_time - pretransfer_time - RTT (из времени отправки запроса на получение данных и получения первого байта вычитаем задержку соединения).
Да, результат не абсолютно точный т.к. RTT не является константой, но погрешность на самом деле не большая и сглаживается использованием одновременно нескольких источников.
Со штампами времени TCP точность была бы гораздо выше, но исходя из спецификаций эта опция может быть отключена в настройках сервера и метод не является универсальным.

Процессор, Жесткий диск, База данных

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

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

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

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

Загрузка CMS

Показатель разделен на две части - первая и повторная загрузка т.к. получаемые значения существенно различаются.
Тесты выполняются путем вызова экземпляра соответствующей системы и измерения времени загрузки.

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

В дополнение к непосредственному выполнению кода ядра, время первой загрузки платформы характеризуется необходимостью компиляции исходных кодов. Результаты компиляции сохраняются в OPcache, что делает повторные обращения намного быстрее.

Повторные запросы характеризуют непосредственное время выполнения кода ядра. Готовый к выполнению код загружается из OPcache без компиляции.

Сеть

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

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

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

В данный момент контроль качества информации осуществляется вручную.
При существенных изменениях в рейтинге (скачек производительности) проверяю признаки:

Соответствие изменений производительности типовым рассылкам о технических работах (не афишируемые изменения).
Изменение адреса сателлита (смена сервера).
Reverse IP Lookup (количество соседей).
Логи обращений (разогревание страниц).
Не типовое поведение ресурса, подозрительные заголовки ответов или stale content (принудительное кеширование).

Если есть хоть какие-то признаки - анонимно разворачиваю дополнительный сателлит и проверяю идентичность показателей.

В планах есть создание автоматизированной системы отслеживания, но не в ближайшее время.