Статьи Архив статей

Перевод: Мациевский Николай aka sunnybear
Опубликована: 24 апреля 2009

Сделай свой сайт быстрее и дешевле за 5 минут

Примечание: ниже находится перевод заметки Make your site faster and cheaper to operate in one easy step, в которой автор описывает применение gzip-сжатия с финансовой точки зрения. Мои комментарии далее курсивом.

Ваш сервер изпользует gzip-сжатие? По-видимому, нет. Я написал простой скрипт, чтобы проверить 30 исходящих ссылок с news.yc и установить, используют ли эти сайты gzip. Только 18 прошли проверку, тогда как оставшиеся 12 очевидно тратили деньги зря на избыточный трафик и были совершенно напрасно медленнее товарищей.

Проверьте ваш сайт здесь.

Некоторые думают, что gzip «слишком медленный». Это не так (для полноты картины можно ознакомиться с этими двумя статьями). Ниже приведен характерный пример (исполняемый на моем ноутбуке), в котором используются данные, полученные с одной из ссылок с news.ycombinator.com:

$ cat < /tmp/sd.html | wc -c
146117
$ gzip < /tmp/sd.html | wc -c
35481
$ time gzip < /tmp/sd.html >/dev/null
real    0m0.009s
user    0m0.004s
sys     0m0.004s

Всего лишь 9 мс потребовалось на то, чтобы сжать 146117 байтов HTML-кода (и это еще включало издерки на создание нового процесса и проч.), при этом результирующий файл занимал всего лишь 24% исходного. Если опираться на эти данные, то сжатие 1 Гб информации потребует 66 процессорного времени. Если повторить наш тест с реальным файлом большего размера, то мы получим результат уже порядка 42 с/Гб, поэтому 66 секунд будет недостижимым максимумом (на самом деле автор кривит душой: нам не важно, за сколько сожмется 1 Гб информации в виде одного файла — нам важно, за сколько сожмутся 10000 файлов по 100 Кб каждый или даже 100000 по 10 Кб, в этом ключе характерной цифрой будет 100 с/Гб).

Я уже слышу гневные возгласы некоторых владельцев сайтов, которые говорят, что не могут себе позволить потратить несколько дополнительных миллисекунд на сжатие данных, пусть даже это сделает их страницы более быстрыми. Однако давайте взглянем на расценки Amazon на процессорное время и трафик. Согласно их прайсингу, «маленькая» установка (одно ядро) стоит $0,10 / час, а передача данных стоит $0,17 / Гб (хотя и уменьшается до $0,10 / Гб при объемах более 150 Тб / месяц, что, по-видимому, не ваш случай).

Так вот, используя эти данные, можно легко подсчитать, что на gzip-сжатие 1 Тб данных будет потрачено $1,88 на Amazon EC2, и $174 для того, чтобы передать этот же самый 1 Тб. Если вместо того, чтобы передавать несжатые данные, вы их заархивируете (и получите четырехкратное уменьшение в размере, что вполне стандартно для HTML, в некоторых случаях можно получить и пятикратное), то стоимость передачи этих данных составит уже $43,52.

Итог

с gzip: $1,88 на процессор + $43,52 на канал = $45,40 + счастливые пользователи

без gzip: $174,00 на канал = $128,60 выброшенных на ветер + менее счастливые пользователи

Еще одним исключение из этого правила будет в том случае, если ваш веб-сервер почему-то не поддерживает gzip. К счастью, существует довольно простое решение данной проблемы: разместите nginx в качестве фронтенда для ваших серверов. Так мы и поступили для FriendFeed, и теперь все работает намного лучше (мы используем сервер на python ручной работы на основе epoll). Nginx выступает в роли прокси-сервера: внешние просители общаются с nginx, а nginx уже общается с уже установленным произвольным сервером (и попутно еще может архивировать сам ответ сервера и делать много других полезных вещей).

Читать дальше

Все комментарии (habrahabr.ru)