Как стать автором
Обновить

Комментарии 40

"gzip = чтение/записать на диск + инициализация библиотеки + создание архива"

исправить на Запись. ;)
на высоконагруженных проектах не стоит сжимать файлы каждый раз
для высоконагруженных проектов под nginx, можно использовать http_gzip_static_module http://wiki.codemongers.com/NginxHttpGzi… :)
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, познавательно.
Дело, конечно, ваше, но зачем переносить статью?
ощущается довольно много работы ушло на создание такого материала, вполне обосновано его дарить публике, но и оставить непосредственное авторство. можно понять, подобный вариант даже лучше просто ссылки-анонса
Впринципе результаты ожидаемые. Хотя в данном случае я надеялся увидеть выкладки не по статическим данным, а по динамическим... А по статике и так понятно - сжали один раз и забыли.
чем в Вашем понимании статические данные от динамических для gzip'а отличаются? и те, и другие — это просто набор байтов, но полученных немного по-разному. Способ получения начального объема информации на результаты по быстроте сжатия и передачи этой информации, по-моему, очень слабо влияет (если вообще влияет).
я возможно упустил, а есть график зависимости использования cpu от степени сжатия c 1 по 9-й
нет, не делал. В тестах использовалась дефолтная (7 вроде) степень сжатия. У Apache обычно от 3 до 7 используется, по-моему.
жаль :) если будет возможность, сделайте, у nginx дефолтовая 1, не думаю что там дефолтовая максимальная стоит, имхо 3 и не выше, на http://www.zlib.org не нашел почему-то в доках.
я имел в виду апач, судя по докам он берет дефолтовую zlib
для примера... 64139 байт html
gzip -1 = 12891 байт
gzip -9 = 10726 байт
gzip -3 = 12300
дык статику достаточно сжать один раз после изменения и потом только отдавать, а динамические данные придётся сжимать при каждом запросе.
значит, это модель для динамических запросов, как наиболее нагружающих сервер на сжатие — ведь сравнивались расходы на сжатие с расходами на передачу. А первые всегда будут только в случае динамического контента.
а то в nginx ставлю то 3 то 9, к своему стыду, ни разу не пробовал замерять результат
Смотрел тесты давно, правда тестировали IIS. Наиболее выгодным уровнем сжатия был 9. Максимально возможный 10, вроде, могу ошибаться.
Я считаю, что, наоборот, сильно влияет. Генерация динамических данных на сервере занимают больше памяти, поэтому чем быстрее отдаете их, тем быстрее память освобождается для следующих запросов
>> gzip = чтение/записать на диск + инициализация библиотеки + создание архива

а при чём тут запись на диск? вы же сами позднее говорите:

>> любой веб-сервер и так берет файл из файловой системы и архивирует уже в памяти, а потом пишет в сокет
в тестах использовался "чистый" gzip. Apache вообще не участвовал из-за большой погрешности на сетевые задержки
а погрешность на параллельные дисковые операции чем-то проще?
не понял Вашего вопроса. Из модельной зависимости исключены (во возможности) любые погрешности, не относящиеся к использованию процессора/оперативной памяти
неудобно, что не на всех графиках шкалы подписаны
Спасибо конено, но дисковая подсистема получилась какая-то сферическая в вакууме. Если уж меряли, то напишите, под какой осью-ядром, какая ФС использовалась, что за винты.
нас не забанят!
Хм уже который год использую гзип сжатие на сайтах.
Среднее значение работы zlib:0,002с GZIP:71%
Те тратится всего ничего, а уменьшается почти в два раза данные.
Сжимается каждый раз на лету.
Размер тестовой страницы 12КБ

Немного не понятны слова о записи\чтения диска.. Вроде как исключительно CPU bound
Ну а если с процом совсем плохо то можно перейти на deflate сжатие.
Оно к сожалению работает очень далеко не везде, зато сжимает файлы практически также(проверял 1-2% разницы, в обе строны) но проца требует на сервере много меньше
Подпишите графики!
Неучтено влияние дискового кеша.

99% что все последующие чтения одного неизменённого файла проводились из диского кеша.
(в выводе free его размер указан в последней колонке)
Алексей, поясните Вашу мысль. Сначала все файла архивировались, потом просто открывались. Дисковые операции идентичны, чего, собственно, и хотелось достичь. Или Вы имеете в виду другое?
Когда Вы читаете некий файл в первый раз он действительно считывается с жесткого диска. Когда Вы читаете этот же файл (и он с прошлого чтения не менялся) он читается уже из дискового кеша в оперативной памяти. Т.е. как таковая дисковая операция происходит только один раз для каждого файла.

Я говорю про Linux, под другими разновидностями Unix это может быть по-другому.
к сожалению, Вы не ответили на вопрос: почему Вы считаете, что что-то оказалось не учтено, ведь дисковые операции в обеих сериях были идентичны
Все "идентичные операции" были из кеша и дисковых операций практически не было. Т.е. они не учтены.

Обычно принято при таких тестах очищать дисковый кеш тем или иным способом.
при чем здесь дисковые операции и взятия из кеша? ведь оценивались затраты на архивирование, а не на работу с файловой системой
В статье описываются некие "издержки на файловую систему", я говорю о них.
я так понимаю, основная претензия к термину "издержки на файловую систему"? Могу переформулировать как "издержки на файловую систему и дисковый кеш", так Вас больше устроит?
не открывается почему-то статья :/
НЛО прилетело и опубликовало эту надпись здесь
недавно тестировал mod_deflate
15 тыс хостов
по данным cacti уменьшился исходящий трафик в пике с 10мбит до 2мбит
немного увеличилась нагрузка на cpu +3-5%
Opteron 246 2Ghz (cpufreq 1Ghz)
RAM 1gb
scsi
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.