вс, 7 апр. 2019 г. в 23:22, Slawa Olhovchenkov <s...@zxy.spb.ru>:
> On Sun, Apr 07, 2019 at 11:12:50PM +0500, Илья Шипицин wrote: > > > > > естественно. я предполагаю, что тот, кто будет сравнивать, понимает > это. > > > > > > и при этом не сообщая ничего о своем (референсном в данном случае) > > > профиле нагрузке? оригинально > > > > > > > это некое предположение, что "среднее хорошо написанное веб-приложение > для > > браузера" работает примерно одинаково. > > я не заметил, там говорилось что нгинкс колокейтится с приложением? > он не статику раздает, не проксей работает? > > > > > > > > > > > > > > > > > > > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер > было > > > как > > > > > > раз про это. > > > > > > > > > > нет никакого смысла смотреть профайлер в данный момент. > > > > > > > > > > > > > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть > > > > профайлер. какие еще есть варианты ? > > > > > > очевидно он расходуется на https, это бесполезное знание. > > > > > > > > > неочевидно. > > например, у нас 70% cpu это компрессия. > > > > опять же, https это как минимум два вида нагрузки - ассиметричные > хендшейки > > и симметричное шифрование. сколько каждого из них, весьма интересно. > > это бесполезное знание, пока мы не узнали что на это расходуется > больше ожидаемого. если у нас большая частота новых соединений то > будет пик в ассиметричных хендшейках и что дальше? так и должно быть. > информация о том, что пик в хендшейках - полезна. допустим, у нас не используется http2 - значит надо его включить допустим, можно увеличить keepalive_requests допустим, можно поревьювить кеш SSL сессий (хотя, по приведенному конфигу - с ним все хорошо) допустим, можно поменять порядок шифрстютов (у GCM хендшейки дешевле) допустим, можно перейти на ECDSA (увеличение производительности от x4 на Xeon до x16 на Celeron) > и смотреть надо на это для начала, а не профайлинг запускать. > без профайлинга непонятно, действительно ли ssl в топе. > > да и вообще, поинтересоваться что за процессор и все такое. > > > из интересных моментов, каким-то странным образом при сборке портов > > freebsd, мы умудрились скомпилировать openssl с выключенной ассемблерной > > оптимизацией. > > это надо было постараться, да. > даже дважды (т.е. что бы для начала системный не устроил) > на freebsd до недавнего времени в base system поставлвлся openssl-1.0.1, постарались мы ровно один раз, когда "убрали" галочку с ассемблерной оптимизации > > > по профайлеру увидели, что 25% cpu уходит на "big numbers" арифметику > > (которая в случае включенной ассемблерной оптимизации умножилась на > ноль). > > > > еще из интересных моментов, был странный опыт с подменой ответа (какой-то > > баг чинили), вылилось это в то, что раздача инсталяторов (при обновлении > > тимсити) привела к всплеску cpu. увидели это тоже по gperftools > > это проявлялось тоьлко на https? > это пример того, как при помощи профайлера найти узкое место. проявлялось это, понятно, в единственной ситуации, вышел новый релиз teamcity, и несколько десятков агентов пошли скачивать инсталяторы. и это пошло сквозь регурярку > > > сколько раз использовал gperftools, еще не было повода пожалеть. > > ни разу не использовал и не жалею. > предпочитаю pcstat, но тогда когда имеет смысл. > вариантов профилирования миллион. неплохой обзор, например, тут http://openresty.org/slides/nginx-conf-2018/#1 > > _______________________________________________ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
