Ars Longa, Vita Brevis » нагрузка

nginx и gzip_static: еще один способ снизить нагрузку на сервер

Vladimir — Sun, 08 Nov 2009 10:09:11 +0000

Отдача предварительно сжатых файлов для снижения нагрузки на процессор

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

В Apache для этих целей используется mod_deflate, в nginx — ngx_http_gzip_module.html. В других web-серверах используются похожие решения.

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

Для nginx есть простой вариант, который позволяет избежать повторного сжатия — использование модуля ngx_http_gzip_static_module. Но этот модуль по умолчанию не собирается — поэтому нужно разрешить его сборку путём передачи параметра --with-http_gzip_static_module скрипту configure.

Включается модуль путём добавления директивы gzip_static on; в блок http или виртуальный хост, после чего nginx будет отдавать вместо обычного файла предварительно сжатый файл с таким же именем и дополнительным расширением .gz. То есть если есть файл index.html.gz, то nginx будет отдавать его при запросе к файлу index.html.

Дело осталось за малым — сжать все статические файлы. И задать им ту же дату модификации, что у исходного файла.

Вручную это делается так:

gzip -9 -c index.html > index.html.gz
touch -r index.html index.html.gz

Но сжимать все файлы вручную — это скучно и муторно. Можно воспользоваться двумя скриптами:

#! /bin/sh

EXTENSIONS="txt|html?|css|js|xml|ico|patch|diff|c"

if [ -z "$1" ]; then
DIR="`pwd`"
else
DIR="$1"
fi

find $DIR -type f -regextype posix-egrep -regex ".*\.($EXTENSIONS)\$" -exec `dirname $0`/do-compress.sh '{}' \;

#! /bin/sh

MINSIZE=100
GZIP="gzip -9 -c -n"
AWK=awk
TOUCH=touch

if [ -n "$1" ]; then
GZ_NAME="$1.gz"
DATA_PLAIN=`stat --format "%s %Y" "$1"`
PLAIN_SIZE=`echo "$DATA_PLAIN" | $AWK '{ print $1}'`
PLAIN_MTIME=`echo "$DATA_PLAIN" | $AWK '{ print $2}'`

if [ $PLAIN_SIZE -lt $MINSIZE ]; then
echo "Ignoring file $1: its size ($PLAIN_SIZE) is less than $MINSIZE bytes"
exit 0;
fi

if [ -f "$GZ_NAME" ]; then
GZIPPED_MTIME=`stat --format "%Y" "$GZ_NAME"`
if [ $GZIPPED_MTIME -eq $PLAIN_MTIME ]; then
echo "Ignoring file $1: there is a compressed file $GZ_NAME with the same modification time"
exit 0
fi
fi

$GZIP "$1" > "$GZ_NAME"
$TOUCH -r "$1" "$GZ_NAME"
echo "Compressed $1 to $GZ_NAME"
fi

Файлы нужно поместить в один и тот же каталог, сделать исполняемыми (chmod 0755 compress.sh do-compress.sh) и немного настроить.

В файле compress.sh задаётся список расширений (регулярным выражением) файлов, которые нужно сжимать:

EXTENSIONS="txt|html?|css|js|xml|ico|patch|diff|c"

Для тех, кто с регулярными выражениями не знаком, есть простое правило: новые расширения разделяются вертикальной чертой. Иными словами, если нужно сжимать файлы с расширением .svg, то строка выше примет следующий вид:

EXTENSIONS="txt|html?|css|js|xml|ico|patch|diff|c|svg"

В файле do-compress.sh единственным параметром, который, вероятно, придется изменить, является MINSIZE. Он задаёт минимальный размер (в байтах) файла, который стоит сжимать. По умолчанию это 100 байт, по идее, должно быть нормально.

Запускается скрипт так (предполагая, что он находится в текущем каталоге):

./compress.sh /path/to/blog

Параметр, передаваемый скрипту — это путь к каталогу, где находится блог (сайт): скрипт рекурсивно обработает все подкаталоги.

Скрипт нужно запускать каждый раз (да, есть такой недостаток), когда изменился/добавился какой-либо подходящий для сжатия файл. Например, если вы изменили файл со стилями темы WordPress. Скрипт не будет пытаться сжимать файл, если существует сжатый файл с одинаковым временем последнего изменения — при последующих запусках будут сжиматься только новые и изменённые файлы. Что значительно снижает ресурсоёмкость процесса.

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

Разочарую всех тех, кто думает, что снижение нагрузки будет кардинальным: вряд ли. Но всё зависит от железа. Чем меньше мощность сервера, тем больше снижение нагрузки.

Обновление 8 мая 2011: добавил -n в командную строку gzip: данная опция исключает имя файла из архива (оно там все равно не нужно), что позволяет сэкономить еще десяток байт.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

WP Super Cache vs HyperCache vs W3 Total Cache vs MaxSite Cache

Vladimir — Fri, 06 Nov 2009 10:59:55 +0000

Сравнение различных плагинов кэширования для WordPress

Для WordPress написано много кэширующих плагинов, предназначенных для борьбы со слабой производительностью сервера (либо кривыми руками администратора, который не в состоянии настроить PHP/MySQL). Простой пользователь зачастую задаётся вопросом: какой же из плагинов выбрать?

В данной статье я рассмотрю наиболее популярные плагины (WP Super Cache, Hyper Cache, W3 Total Cache и MaxSite Cache), а затем расскажу о результатах жестокого теста, которому я подверг все эти плагины.

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

Поехали.

WP Super Cache написан Donncha O’Caoimh, одним из разработчиков WordPress. Про своё отношение к этому плагину я уже писал. Плагин разрабатывался как замена WP-Cache. Ключевой особенностью плагина является генерация статических HTML-страниц таким образом, что они будут отдаваться Web-сервером — минуя PHP.
Hyper Cache. С ним я тоже сталкивался, и какое-то время плагин стоял у меня на сайте. Плагин написан гораздо проще, чем WP Super Cache и имеет более высокий рейтинг на wordpress.org.
W3 Total Cache — новое слово в кэшировании. Поддерживает сжатие скриптов, CSS, кэш для базы данных, работу с CDN и многое другое.
MaxSite Cache — отечественная разработка, при этом платная. Я тестировал Lite-версию, так как покупать полную версию чисто для тестирования желания нет. По словам автора, выйдет абсолютным победителем при сравнении с WP Super Cache и компанией.

Для теста была взята машина такое конфигурации: Intel(R) Xeon(R) CPU X3320 @ 2.50GHz, 4 ядра, 3 MiB кэш, 8 GiB DDR-2 RAM, 2×500 GB SATA, RAID1 (ARC-1210 4-Port PCI-Express to SATA RAID Controller), 82572EI Gigabit Ethernet Controller.
Операционная система: Ubuntu 9.10 64-bit Server Edition
Веб-сервер: nginx 0.8.19
PHP: 5.2.10.dfsg.1-2ubuntu6.1 (FastCGI) + xCache 1.2.2-5, 75 процессов.

На тестируемой странице 25 несложных запросов, время их выполнения — 0.00993 сек.

На сайт натравливался ApacheBench — 10,000 запросов в 100…500 потоков. Это создаёт весьма приличную нагрузку, так как запросы идут один за другим.

Базовая нагрузка — 100 параллельных потоков. Я увеличивал количество потоков до тех пор, пока web-сервер не стал отдавать ответ, отличный от 200. Более 500 потоков не тестировал.

	WordPress	WP Super Cache 0.9.7		Hyper Cache 2.6.2		MaxSite Cache Lite			W3 Total Cache 0.8
Количество потоков	100	100	500	100	250	100	500	130	100	130
Время тестирования, с	677.442	1.115	1.079	18.736	8.633	3.291	2.501	2.992	21.284	21.086
Количество ошибок	0	0	0	0	3663	0	2713	0	0	0
Скорость, запрос/с	14.76	8967.28	9268.36	544.20	1158.30	3038.98	3997.80	3341.72	469.84	474.25
Среднее время обработки запроса, мс	6774.423	11.152	53.947	183.757	215.833	32.906	125.069	38.902	212.838	274.116
Среднее время обработки запроса по всем потокам, мс	67.744	0.112	0.108	1.838	0.863	0.329	0.250	0.299	2.128	2.109
Скорость передачи, Кбайт/с	175.12	106154.90	109865.55	6393.68	8754.04	35537.15	34413.87	39075.95	4928.74	4974.58
Порог завершения 95% запросов, мс	9188	11	27	394	268	52	91	58	344	364

То, что не вошло в таблицу: средняя загрузка системы (load average) при тесте голого WordPress зашкаливала за 60. При тесте WP Super Cache и MaxSite Cache я не успевал ее измерить (была ничтожной). С Hyper Cache и W3 Total Cache загрузка доходила до где-то 10. Так что кэширование работает и выполняет свою работу — снижает нагрузку на сервер.

«Голый» WordPress тестировать более, чем со 100 потоками смысла нет

В ходе тестирования выяснился абсолютный лидер — WP Super Cache. Скорость отдачи кэшированных страниц поистине фантастическая — почти 800 мегабит/сек. Хотя такая скорость — это больше заслуга nginx.

MaxSite Cache Lite на 100 параллельных потоках проиграл WP Super Cache практически в пять раз! Причина понятна: WP Super Cache создает статические файлы так, что web-сервер их может отдавать клиенту без привлечения PHP-интерпретатора. А статические запросы при прочих равных всегда быстрее динамических. Так что платить 30 WMZ за полную версию MaxSite Cache я пока не готов

Среди остальных плагинов MaxSite Cache выигрывает благодаря свой простоте: минимум проверок, никаких регулярных выражений и лишних подключаемых файлов. Но даже такой подход не спасёт от хорошего SlashDot-эффекта: какой-то процент пользователей будет видеть ошибку сервера, для других возрастёт время генерации страницы. Это касается и остальных плагинов. Мораль: подключение PHP-интерпретатора — дорогое удовольствие.

По поводу масштабируемости: более 130 потоков не пережил ни один кэш (кроме WP Super Cache).

Аутсайдером, на мой взгляд, оказался W3 Total Cache — при почти одинаковой с Hyper Cache нагрузкой на сервер, время отдачи страниц было значительно выше. Хотя если бы тест был не таким искусственным, то производительность W3 Total Cache могла быть и более высокой. Хотя во многом W3 Total Cache делает то, что опытный системный администратор может настроить на уровне сервера.

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

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

Вообще, как показывает мой опыт, прежде чем использовать плагин кэширования страниц, имеет смысл все же грамотно настроить сервер (обращайтесь). Например, если вместо Apache поставить nginx, можно освободить довольно много драгоценной памяти (prefork у Apache — это весьма сильный убийца производительности); если увеличить размер буфера ключей MySQL, можно добиться уменьшения дисковой активности. Если поставить opcode cacher (APC, xCache, eAccelerator), то можно значительно снизить затраты на перекомпиляцию PHP-кода и уменьшить время отклика системы. Если использовать оптимизатор, встроенный в eAccelerator, то можно повысить производительность PHP-кода. Анализ производительности MySQL-запросов и знание принципов работы оптимизатора помогут переписать слабые запросы/добавить отсутствующие индексы в базу данных. Простор для действий довольно-таки большой. И динамика страниц остаётся

WP Super Cache и высокая нагрузка: часть 2

Vladimir — Wed, 29 Jul 2009 02:03:31 +0000

Стоит ли овчинка выделки?

Вчера я наконец-то поднял munin и новый monit на сервере, а сегодня посмотрел на результаты мониторинга. Самое первое, что бросилось в глаза: iostat показывает очень большое количество записей (превышавшее количество чтений почти в тысячу раз).

На сервере живут четыре сайта на WordPress, два из которых (littlefox.ru и cat-tv.ru) находятся в Alexa Top 100,000 (они создают основную нагрузку на сервер).

Особенность обоих сайтов — они используют небезызвестный плагин WP Super Cache. Мне с этим плагином приходилось неоднократно сталкиваться, и не всегда с хорошей стороны (так получилось), так что я имею представление о том, как он работает.

С целью поэкспериментировать мы отключили WP Super Cache. В результате получилась такая картина.

Так сложилось, что WP Super Cache мы отключили практически при пиковой посещаемости (хорошо видно на графике «eth0 traffic»), и тем интереснее смотрятся результаты. Практически сразу упало количество записей на диск (дисковая подсистема вздохнула с облегчением): при количестве записей, тысячекратно превышающих количество чтений, эффективность дискового кэша, очевидно, падает. В случае с виртуальным сервером такая нагрузка могла бы его положить: дело в том, что виртуализаторы не очень хорошо справляются с операциями ввода/вывода (это их слабое место); как результат, от этого начинает увеличиваться нагрузка на процессор (все больше времени проводится в iowait).

Также, как это ни странно, упала нагрузка на процессор! Причём заметнее всего это отразилось на user time (а не на system, как можно было бы ожидать) — если внимательно посмотреть на графики «CPU Usage» и «Load Average», то можно заметить, что при примерно одинаковом количестве посетителей (я сужу по объемам отдаваемого трафика) нагрузка при отключенном WP Super Cache оказывается меньшей (причем это заметно даже при низкой нагрузке — впрочем, при низкой нагрузке, наверное, любой кэш не особо эффективен из-за затрат на реализацию кэширования)! Так же уменьшилось количество переключений контекста (что, видимо, и объясняет уменьшение system time) и уменьшилось количество прерываний от контроллера жесткого диска.

А вот статистика MySQL далеко не однозначна:

С одной стороны, вроде бы и среднее количество запросов в секунду резко упало, но с другой стороны, это произошло до отключения WP Super Cache. Также заметно, что при выключенном WP Super Cache кэш запросов стал медленно таять (хотя это можно объяснить падением нагрузки и чисткой кэша). Хотя процентное отношение количества запросов, результат для которых был взят из кэша, весьма впечатляет. Что значит грамотная настройка MySQL. Тем не менее, данных для однозначных выводов недостаточно.

Перейдём к ответу на вопрос, стоит ли овчинка выделки. Как обычно, однозначного ответа нет. Нужно смотреть в каждом конкретном случае. Тем не менее, если сайт стоит на виртуальном сервере, то высокая нагрузка при включенном WP Super Cache может его убить. Если есть достаточно памяти (что на виртуалках большая редкость), то имеет смысл помещать каталоги с кэшем на RAM-диск и разгрузить дисковую подсистему. При высокой нагрузке на выделенном сервере нужно очень внимательно смотреть на конфигурацию MySQL, а также типы запросов. Если же сайт стоит на shared-сервере, то выбор здесь небольшой: либо отказаться от плагинов, которые грузят MySQL, либо сменить WordPress на что-то более легкое. Кэширование на shared-сервере, как правило, не оправдывает себя (во многом зависит от жадности хостеров, которые на одном сервере стремятся разместить как можно большее количество сайтов). Тем же, кто имеет административный доступ на сервер, я бы очень рекомендовал мониторинг сервера (munin, nagios/nagvis и т.п.) со включенным и выключенным кэшем. Возможно, что результат очень сильно удивит