Pull to refresh

Comments 40

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

исправить на Запись. ;)
на высоконагруженных проектах не стоит сжимать файлы каждый раз
UFO landed and left these words here
Дело, конечно, ваше, но зачем переносить статью?
ощущается довольно много работы ушло на создание такого материала, вполне обосновано его дарить публике, но и оставить непосредственное авторство. можно понять, подобный вариант даже лучше просто ссылки-анонса
Впринципе результаты ожидаемые. Хотя в данном случае я надеялся увидеть выкладки не по статическим данным, а по динамическим... А по статике и так понятно - сжали один раз и забыли.
чем в Вашем понимании статические данные от динамических для 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 это может быть по-другому.
к сожалению, Вы не ответили на вопрос: почему Вы считаете, что что-то оказалось не учтено, ведь дисковые операции в обеих сериях были идентичны
Все "идентичные операции" были из кеша и дисковых операций практически не было. Т.е. они не учтены.

Обычно принято при таких тестах очищать дисковый кеш тем или иным способом.
при чем здесь дисковые операции и взятия из кеша? ведь оценивались затраты на архивирование, а не на работу с файловой системой
В статье описываются некие "издержки на файловую систему", я говорю о них.
я так понимаю, основная претензия к термину "издержки на файловую систему"? Могу переформулировать как "издержки на файловую систему и дисковый кеш", так Вас больше устроит?
UFO landed and left these words here
недавно тестировал mod_deflate
15 тыс хостов
по данным cacti уменьшился исходящий трафик в пике с 10мбит до 2мбит
немного увеличилась нагрузка на cpu +3-5%
Opteron 246 2Ghz (cpufreq 1Ghz)
RAM 1gb
scsi
Only those users with full accounts are able to leave comments. Log in, please.