Re: профилирование cpu: обсудим ?

[Илья Шипицин]

пн, 18 февр. 2019 г. в 17:12, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Sat, Feb 16, 2019 at 04:38:53PM +0500, Илья Шипицин wrote:
>
> > привет!
> >
> > посмотрел в вывод
> http://nginx.org/ru/docs/ngx_google_perftools_module.html
> > получил такую картинку
> >
> > https://yadi.sk/i/ai-sUyCK3HasQA
> >
> >
> > вопрос - это нормально, что компрессия занимает СТОЛЬКО ?
>
> Да.  Компрессия - один из наиболее серьёзных потребитилей
> процессорного времени, хуже - только SSL handshake'и.
>

ну то есть, поскольку при штатном использовании массово используются
кипэлайвы и abbrevated handshakes, то из-за этого SSL хендшейки
незначительны?


>
> И, в частности, именно по этой причине gzip_comp_level - по
> умолчанию 1.
>
>
это мы не трогали


> > компрессия включалась без выкрутасов
> >
> >     gzip on;
> >     gzip_types text/css text/javascript application/x-javascript
> > application/javascript text/plain text/xml text/x-component text/json
> > application/json application/octet-stream application/atom image/svg+xml;
> >     gzip_min_length 500;
> >     gzip_disable msie6;
>
> Сжатие application/octet-stream - это обычно не лучший выбор, если
> ресурсы процессора важны.
>

сложно вспомнить, зачем это было сделано. но кажется, что среди общего
трафика того сервера, который профилировался, application/octet-stream не
должно быть много


>
> > из недефолтных настроек
> >
> > proxy_buffering off;
> >
> > (проверю, не влияет ли она).
>
> Влияет, сжатие работает более эффективно, если на вход подаются
> большие блоки (и не делается flush после каждой операции).  Но в
> общей картине это влияние не принципиально, так или иначе сжатие
> требует много процессора.
>

любопытства ради проверю с выключенной и включенной буферизацией


>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190219/77b7dcd6/attachment.html>