Время ответа сервера (хостинга вашего сайта) — первый кирпичик в здание оптимизации скорости сайта. Быстрый сайт начинается с быстрого хостинга или быстрого сервера. Как выяснить, что на сервере тормозит и как это исправить?

Выясняем корень зол

Первое, что мы делаем, — это проверяем ситуацию. Качественно протестировать время ответа сервера можно с помощью распределенной сети WEBO Pulsar или Ping Admin. В первом случае вам нужно обратить внимание на показатель ожидание ответа — он покажет точное время ответа сервера. Во втором случае нужно взять время загрузки сайта и разделить пополам (поскольку в него кроме ожидания ответа сервера будет входить DNS-запрос, время подключения и время загрузки данных).

Нормальным показателем будет 200-500 мс (0,2-0,5 с). Если ваш хостинг отвечает столько — значит, можно приступать к следующим шагам по ускорению сайта. Если время ответа сервера большое 500 мс — значит, есть серьезные проблемы со скоростью сайта на стороне сервера (хостинга), и их нужно решать.

Причины большого времени ответа сервера

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

Основные проблемные места производительности сервера:

1. Используемый веб-сервер (Apache, IIS). Ряд веб-серверов архитектурно не предназначены для обработки большого количества запросов, поэтому могут создавать дополнительные задержки даже при выдаче статических файлов. Для быстрой работы веб-сервера необходимо использовать nginx (в связке с Apache, php-fpm или другими серверами приложений для обработки серверных вычислений).
2. Использование OpCache (акселератора PHP). Кэширование исполняемого кода (скриптов сайта) — обычно первый шаг к быстрому серверу. Кэширование позволяет не переводить каждый раз PHP-инструкции в бинарный код, а использовать уже готовый результат. Это кэширование не имеет ничего общего с кэшированием результата выполнения PHP-скриптов (например, кэширование HTML-страниц или MySQL-запросов).
3. Запросы к базе данных. Как минимум, половина всех задержек на стороне сервера складывается из запросов к базе данных. При правильной настройке таблиц (индексов) в базе данных и структуры запросов, а также кэшированию наиболее часто используемых результатов или пересчету промежуточных результатов в отдельные таблицы возможно снизить потребляемые серверные ресурсы в несколько (десятков или даже сотен) раз.
4. Сложная логика обработки данных. У вас может быть уже идеально настроенная база данных, но выборка большого количество элементов и произведение над ними многочисленных операций (перебор в цикле) способно существенно затормозить ваш сайт. Профилирование времени выполнения серверных скриптов и устранения ненужных операций (упрощения серверной логики) может также дать существенный результат в плане серверной производительности.
5. Обращение к сторонним сервисам. Если в коде серверных скриптов есть запросы к сторонним сервисам для получения данных — будьте готовы к сюрпризам. Если вы не контролируете производительность источников данных, которые запрашиваются, то время ответа вашего сервера может непредсказуемо изменяться — в зависимости от времени ответа сторонних сервисов. Хорошей практикой является использование в серверных запросах только внутренние источники данных (производительность которых вы контролируете), либо запрос данных на клиентской стороне в отложенном режиме (по крайней мере, это гарантирует стабильное время ответа вашего сервера в случае отказа какого-либо внешнего сервиса).

Первоочередные меры по ускорению сервера

1. Настроить использование nginx (в связке с Apache+mod_php, php-fpm или IIS для выполнения серверной логики). Это сократит время на обработку запросов к статическим файлам сайта и повысит отказоустойчивость.
2. Настроить кэширование исполняемого кода. Начиная с PHP 5.3 Zend Guard уже поставляется по умолчанию, поэтому вам нужно либо проверить, что он уже используется для вашего сайта, либо использовать любой альтернативный менеджер кэша исполняемого кода: APC, OpCache, xCache. Проверить использование этого кэша достаточно просто: нужно создать на сайте файл info.php с кодом <?php phpinfo(); ?> и открыть его в браузере. Если на странице присутствуют модули APC, Zend Optimizer, Zend Guard, xCache или OpCache — то все хорошо.
3. Проверить задержки выполнения скриптов. После подготовки фундамента (веб-сервера и кэширования исполняемого кода) можно взглянуть на задержки непосредственно серверной логики. Лучшим решением будет серверное кэширование страниц целиком (если возможно отображение одних и тех же страниц всем или почти всем пользователям сайта). Если серверное полностраничное кэширование невозможно, то необходимо настраивать блочное кэширование отображаемых на страницах блоков данных (через Memcached). Также эффективным может оказаться удаление неиспользуемых данных из базы данных или настройка индексов (для оптимизации запросов).

После выполнения всех этих мер время ответа сервера для всех страниц сайта обычно уменьшается в 5-10 раз. Этого бывает достаточно для перехода к следующим мерам по ускорению сайта — сжатию данных и объединению файлов. В облаке Айри вы можете настроить кэширование как всех страниц сайта с заданным периодом (например, на час или на сутки), так и каких-либо отдельных разделов или даже страниц, применяя авто-обновление кэша раз в минуту, раз в 10 минут или раз в сутки («вечное» кэширование).