<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вс, 7 апр. 2019 г. в 23:22, Slawa Olhovchenkov <<a href="mailto:slw@zxy.spb.ru">slw@zxy.spb.ru</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Apr 07, 2019 at 11:12:50PM +0500, Илья Шипицин wrote:<br>
<br>
> > > естественно. я предполагаю, что тот, кто будет сравнивать, понимает это.<br>
> ><br>
> > и при этом не сообщая ничего о своем (референсном в данном случае)<br>
> > профиле нагрузке? оригинально<br>
> ><br>
> <br>
> это некое предположение, что "среднее хорошо написанное веб-приложение для<br>
> браузера" работает примерно одинаково.<br>
<br>
я не заметил, там говорилось что нгинкс колокейтится с приложением?<br>
он не статику раздает, не проксей работает?<br>
<br>
> <br>
> ><br>
> > ><br>
> > > ><br>
> > > > > Вообще, я с вами согласен, моё предложение посмотреть профайлер было<br>
> > как<br>
> > > > > раз про это.<br>
> > > ><br>
> > > > нет никакого смысла смотреть профайлер в данный момент.<br>
> > > ><br>
> > ><br>
> > > в любом случае, чтобы узнать, на что расходуется cpu, надо смотреть<br>
> > > профайлер. какие еще есть варианты ?<br>
> ><br>
> > очевидно он расходуется на https, это бесполезное знание.<br>
> ><br>
> <br>
> <br>
> неочевидно.<br>
> например, у нас 70% cpu это компрессия.<br>
> <br>
> опять же, https это как минимум два вида нагрузки - ассиметричные хендшейки<br>
> и симметричное шифрование. сколько каждого из них, весьма интересно.<br>
<br>
это бесполезное знание, пока мы не узнали что на это расходуется<br>
больше ожидаемого. если у нас большая частота новых соединений то<br>
будет пик в ассиметричных хендшейках и что дальше? так и должно быть.<br></blockquote><div><br></div><div>информация о том, что пик в хендшейках - полезна.</div><div><br></div><div>допустим, у нас не используется   http2 - значит надо его включить</div><div>допустим, можно увеличить keepalive_requests</div><div>допустим, можно поревьювить кеш SSL сессий (хотя, по приведенному конфигу - с ним все хорошо)</div><div>допустим, можно поменять порядок шифрстютов (у GCM хендшейки дешевле)     <br></div><div>допустим, можно перейти на ECDSA (увеличение производительности от x4 на Xeon до x16 на Celeron)                                  <br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
и смотреть надо на это для начала, а не профайлинг запускать.<br></blockquote><div><br></div><div>без профайлинга непонятно, действительно ли ssl в топе.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
да и вообще, поинтересоваться что за процессор и все такое. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> из интересных моментов, каким-то странным образом при сборке портов<br>
> freebsd, мы умудрились скомпилировать openssl с выключенной ассемблерной<br>
> оптимизацией.<br>
<br>
это надо было постараться, да.<br>
даже дважды (т.е. что бы для начала системный не устроил)<br></blockquote><div><br></div><div><br></div><div>на freebsd до недавнего времени в base system поставлвлся openssl-1.0.1, <br></div><div>постарались мы ровно один раз, когда "убрали" галочку с ассемблерной оптимизации<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> по профайлеру увидели, что 25% cpu уходит на "big numbers" арифметику<br>
> (которая в случае включенной ассемблерной оптимизации умножилась на ноль).<br>
> <br>
> еще из интересных моментов, был странный опыт с подменой ответа (какой-то<br>
> баг чинили), вылилось это в то, что раздача инсталяторов (при обновлении<br>
> тимсити) привела к всплеску cpu. увидели это тоже по gperftools<br>
<br>
это проявлялось тоьлко на https?<br></blockquote><div><br></div><div><br></div><div>это пример того, как при помощи профайлера найти узкое место. проявлялось это, понятно, в единственной ситуации,</div><div>вышел новый релиз teamcity, и несколько десятков агентов пошли скачивать инсталяторы. и это пошло сквозь регурярку<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> сколько раз использовал gperftools, еще не было повода пожалеть.<br>
<br>
ни разу не использовал и не жалею.<br>
предпочитаю pcstat, но тогда когда имеет смысл.<br></blockquote><div><br></div><div>вариантов профилирования миллион.</div><div>неплохой обзор, например, тут  <a href="http://openresty.org/slides/nginx-conf-2018/#1">http://openresty.org/slides/nginx-conf-2018/#1</a><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div></div></div>