У каждого веб-мастера, администратора или менеджера проекта регулярно возникает зуд на тему: а достаточно ли быстро открывается мой сайт? Ну он идёт в любой из 100500 бесплатных измерителей скорости, проверяется там, получает значение в N секунд и успокаивается. Но однажды, глубокой ночью, ему в голову начинает лезть навязчивая мысль: а N секунд – это много или мало? Может быть CMS таки тормозит?
В этом посте я дам методику, которая позволит в первом приближении (вполне достоверно) оценить, является ли ваша CMS тормозящим фактором. Естественно, речь идёт о динамических страницах, так как при отдаче статики (например из кэша nginx, как я это внедрил в UMI) производительность CMS не имеет непосредственного значения.
Для начала вспомним цикл обработки типичного запроса на типичном веб-сервере: человек переходит по ссылке на ваш сайт, запрос принимает nginx, проксирует его ниже на apache, там включается php/mysql/etc…, затем apache и nginx транслируют обратно ответ. Затем браузер инициирует запросы к картинкам и прочей статике, которые обслуживает непосредственно nginx, и apache тут уже роли не играет.
Итак, ключевой вопрос: достаточно ли быстро отрабатывает apache со всей нижестоящей цепочкой? Имеет ли смысл делать оптимизацию быстродействия вообще? Ведь нет смысла тюнить код или базу, если они и так работают заведомо в рамках ожидаемой посещаемости.
Поэтому ключевой вопрос – в том, какова разница между временем отдачи динамически сгенерированной страницы (реальная скорость, с которой её получает посетитель) и временем отдачи её статической копии (теоретический максимум скорости). Располагая этими цифрами, можно сделать вывод о целесообразности затрат на оптимизацию. И вот как это выяснить без применения заумных инструментов:
1. Открываете страницу своего сайта в браузере.
2. Открываете её исходный код.
3. Копипастите всё содержимое в файлик, например mycoolpage.html (подразумевается, что nginx у вас умеет отдавать html-файлы напрямую).
4. Копируете этот файлик в соответствующую директорию вашего сайта (если вы открывали главную страницу, значит в корневую директорию).
Затем открываете свою любимую измерялку быстродействия в двух экземплярах, в одном указываете адрес вашего сайта www.yourdomain.com, в другом – адрес этого файлика www.yourdomain.com/mycoolpage.html. И сравниваете время/скорость загрузки.
В чём смысл: в первом случае у вас отработает вся динамика, и вы получите время/скорость которую имеет ваш обычный посетитель. Во втором случае вы получите тот же самый контент и те же самые объёмы загрузки, но без участия apache/php/mysql/etc. Это наглядно покажет, есть ли у вас тормоза в генерации страниц, и даст вам измеримую разницу в показателях. Которую уже можно устранять тюнингом кода, или не устранять, если это невыгодно бизнесу.
Как использовать эти цифры?
Каждая секунда машинного времени стоит определённую сумму денег. Вы можете выразить её в рублях, пересчитав в секунды ваш ежемесячный тариф хостинга. Или вычислить стоимость секунды как функцию от дохода сайта в месяц, если доход зависит от посещаемости.
Если у вас средний интернет-магазин, то выйгрыш 3-4 секунд может иметь для вас некоторое значение, над которым стоит поработать. А если у вас highload-проект на ~200 выделенных серверах, то даже десятые доли секунд “ненужной” работы сервера приносят вам убытки в сотни долларов. Исходя из этих цифр, можно принять решение, стоит ли заниматься оптимизацией быстродействия и когда нужно её прекратить.
На этом можно было бы закончить, но вот something for advanced users:
Страницы сайтов периодически меняются, изменяется объём контента, и старые цифры становятся неактуальными. Нужно их обновлять. Для этого вы можете написать скриптик, который периодически будет скачивать страницу на тот же сервер и сохранять её html-код в файл. Затем вы можете взять свою любимую систему мониторинга (или заказать у меня) и добавить туда триггер, который будет ругаться при возникновении большой разницы между показателями.
После этого зуд оптимизаторства кода у вас должен пропасть, но может возникнуть зуд настройки nginx и сетевых буферов ОС. Но об этом – в следующий раз. Подпишитесь на RSS, чтобы быть в курсе.