Примечание samlowry: эта заметка — результаты мини-исследования моего уважаемого коллеги ykar-а.
Из трех ботов (msnbot,Googlebot,Slurp) сжатыми странички отдаются только Googlebot-у. Я решил посмотреть что шлют поисковики — вдруг по какой-то банальной причине nginx не понимает что они принимают gzip.
Просниффил трафик на сервере и получил такие запросы:
Сообщение от msnbot
GET /page.html HTTP/1.0
Host: domain.com
User-Agent: msnbot/1.0 (+http://search.msn.com/msnbot.htm)
Accept: text/html, text/plain, text/xml, application/*, Model/vnd.dwf, drawing/x-dwf
Accept-Encoding: identity;q=1.0
From: msnbot(at)microsoft.com
Тут уже сразу понятно, msnbot не поддерживает gzip, о чем даже подчеркивает заголовком Accept-Encoding: identitiy.
Сообщение от Yahoo! Slurp
GET /page.html HTTP/1.0
Host: domain.com
Accept: */*
User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)
Accept-Encoding: gzip, x-gzip
А тут похоже что слурп понимает gzip, но все же почему то ему nginx шлет несжатые данные. Покопавшись в исходниках нашел что по умолчанию nginx не отдает gzip если протокол HTTP/1.0, даже если его об этом просят, нашел опцию gzip_http_version (потом ее и в документации нашел) которая задает минимальный протокол по которому будет отдаватся gzip. Добавив «gzip_http_version 1.0», все заработало — судя по логам контент отдается слурпу сжатым.
Ну и на последок запрос который шлет Googlebot. С gzip-ом у него проблем и так нет так что привожу просто для справки.
Цитата:Сообщение от Googlebot
GET /page.html HTTP/1.1
Host: domain.com
Connection: Keep-alive
Accept: */*
From: googlebot(at)googlebot.com
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Accept-Encoding: gzip
Примечание samlowry: я и раньше предполагал, что как минимум всеведущий Гуглбот умеет брать gzip-нутые странички. Учитывая то, что в дорвеном деле основной контент — это html-страницы, которые, в силу раздутости формата, сжимаются очень хорошо, экономия ресурсов получается значительная. Ну, а про то, что страницы будут выдаваться пользователям гораздо быстрее — тут и говорить не о чем.
Забавно, но у хостеров почему-то не принято ставить по-умолчанию модули сжатия страниц, и даже наоборот — они распространяют слухи, что из-за сжатия страниц сильно увеличивается нагрузка на сервер :-/. У меня соотв. модуль, естественно поставлен, это mod_deflate.
И они правы. В 2005-м, на одном из сайтов пытался включить Gzip. Кончилось это предельной нагрузкой на сервер от 200К уников в сутки. Сервер содержал минимум динамики.
я вам больше скажу — при упаковке контента сервер меньше нагружается за счет разгрузки сетевой подсистемы. ну, а хостеров можно понять — пользователи платят же за траф =)
А разве это проблема отдавать странички не сжатыми, при нынешней-то пропускной способности каналов?… А нагрузка на сервер при включенном сжатии полюбому будет, тут уж надо смотреть, что у вас «уже», канал или ресурсы сервера.
За то что проверили на практике – 5.
Надо кешировать сжатый контент и отдавать его, а не сжимать одно и то же тысячи раз, убивая сервер.
Arser: ты забываешь такую милую мелочь, как кол-во процессов вебсервера, Апача, например. Каждый коннект обслуживает копия процесса. Ты считаешь, что их можно наращивать бесконечно? :-)
Val: mod_gzip так делает, например.
rst: подробности можешь дать, как это вы так его включили? Недавно мы врубали его у моего друга, на адалтном сиджеблоге с сотнями килоюников. Нагрузки не было никакой.
Пингбэк: СоНоты
небольшой офтоп: все кто не выкинул апач, сделайте это!
Soda: хватит тут свою расистсткую агитацию вести, у меня апач отлично работает. Ручки надоте иметь прямые — и апач разгружается мигом.
samlowry, я вообще rst-у писал отвечал, если чё.
samlowry, ты не вдумчиво читал мой пост, я не зря про 2005-й год упомянул. Тогда скорости и сервера были несколько другие.
rst: я всё вдумчиво читаю, просто процедура gzip-сжатия настолько оптимизированна, что серьезных нагрузок создать не могёт. Ну насколько другое железо было? Мы буквально вчера обсуждали этот пост с автором теста, ykar-ом, он говорил о 3% нагрузке на проц при использовании gzip-сжатия. Пусть даже проц был тогда в 10 раз медленнее — это 30% нагрузки, это не может положить сервер.
Могет. Еще как могет.
Она увеличивает время отдачи страницы. Причем, увеличивает больше чем в два раза (для статики). Это говорит о том, что апач дольше обрабатывает запрос, а следовательно, одновременно крутится больше апачей. Больше апачей = больше запущенных процессов httpd = больше памяти. Как только апач добирается до свопа, то случается пиздец, и снежная лавина кажется раем. Выглядит это очень интересно. Вот у тебя LA 5, 2000 коннектов к апачу, а через секунду у тебя уже LA 800 и сервер не отвечает даже на пинги.
>Она увеличивает время отдачи страницы.
Это как сказать. Она увеличивает время от запроса клиента до ответа сервера. Зато она уменьшает время от начала ответа сервера до его конца. Без сжатия будет наоборот — быстрее наступать ответ, но медленнее отдаваться контент.
Так что влоб сказать, что именно со сжатием итоговое время запроса-ответа станет больше нельзя.
Но это все глубокая теория, всё проверяется просто. Вруби сжатие сейчас и скажи, чего получится.
>Это как сказать. Она увеличивает время от запроса клиента до ответа сервера. Зато она уменьшает время от начала ответа сервера до его конца. Без сжатия будет наоборот — быстрее наступать ответ, но медленнее отдаваться контент.
Я говорю о том месте, где работает именно апач — обработка запроса.
т.е. то, что между recv от клиента, и send ему же. как раз в этом промежутке находится сжатие. В этом промежутке — абсолютно все равно какой канал, и насколько быстрее отдается траффик. Это имеет значение ПОСЛЕ send, уже в стеке протокола, где апача уже нет — он отваливается после сенда.
rst: я ровно то же самое и сказал ;-)
где?
«от запроса клиента до ответа сервера»
Нет от запроса клиента, а от вызова функции recv на сервере и до вызова функции send. Между ними происходит формирование контента. И именно здесь проявляется нагрузка утрамбовки, которая не компенсируется скоростью передачи меньшего объема данных по сети.
rst: ок, понял, ты говоришь искл. об уровне сервера. Так почему не компенсируется — я не понял, если ф-ция очень быстрая и лёгкая?
Почитал топик на ВМВ — http://www.webmasterworld.com/forum19/2828.htm — вопрос сугубо индивидуален. Кто-то делает исследования — и говорит, что даже несмотря на «лаг» о котором ты говоришь, паги даже у DSL-щиков начинают грузится быстрее.
Приводят в пример известные контентные сайты, которые юзают сжатие:
http://www.slashdot.org
http://www.cnn.com
и даже Википедия.
Советуют настраивать сжатие 1, т. к. оно даёт 95% КПД сжатия, остальные уровни дают незначительное сжатие при зажоре CPU. Это к тому, что в mod_gzip по дефолту стоит сжатие 6, как в mod_deflate с этим — не знаю.
В то же время есть люди, у которых сжатие дало значительное замедление загрузки, в т. ч. есть и случай, похожие на твой — через 20 минут после включения сжатия сервер лёг.
Я полностью согласен, что загружаться будет гораздо быстрее. Но, в некоторых случаях, это как езда на максимальных оборотах на машине (красная зона) : динамика +20%, однако за 10 минут — перегрев ГБЦ и клин.
>Между ними происходит формирование контента. И именно здесь >проявляется нагрузка утрамбовки, которая не компенсируется >скоростью передачи меньшего объема данных по сети.
rst, почему ты так решил, это подтверждено реальными данными или это твой неудачный опыт? я с уверенностью утверждаю, что опытным путем получено что — при включении лекгой упаковки gzip на серверах отдающих 200-300 мегабит сетевая подсистема сервера разгружается, клиенты получают контент быстрее, нагрузка на сервере уменьшается (freebsd, сетевая карта не в режиме polling)
В свое время(году эдак в 2005) поставил GZip сжатие на одном сайте, все отлично работало. Единственное что яндекс выдавал абракадабру в сниппете страницы.
Кстати, в Safari под mac номер комментария практически полностью закрывает имя комментатора.
На нескольких сайтах использовал сжатие. Проблем с сервером не возникало. Дает ли эта процедура какой либо положительный эффект сказать не могу