<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">30 января 2013 г., 19:30 пользователь Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Wed, Jan 30, <a href="tel:2013" value="+9722013">2013</a> at 05:51:25AM -0500, teo wrote:<br>
<br>
[...]<br>
<br>
> ... и максимальном кол-ве запросов на одном IPv4 в 65536 ...<br>
<br>
Безотносительно к остальному тексту - вот это вот достаточно<br>
частно встречающееся заблуждение, поэтому слегка потопчусь, дабы<br>
развеять/прояснить.<br>
<br>
Нет ограничения в 64k соединений на адрес.  Есть ограничение<br>
уникальность комбинации src_ip:src_port:dst_ip:dst_port.  И из него<br>
следует, что при фиксированных dst_ip, dst_port (т.е. ip сервера,<br>
и порт 80) - остаётся два свободных параметра, src_ip и src_port.<br>
<br>
Если мы зафиксируем вдобавок ещё и src_ip - то, действительно, у<br>
нас останется для варьирования только src_port, и больше 64k<br>
соединенией никак не открыть.  Но - это так только при<br>
фиксированном src_ip, т.е. от _одного_ клиента.<br>
<br>
Если же клиентов много (а у типичного веб-сервера их много) - то<br>
соединений может быть сколько угодно (до 64k от каждого клиента).<br>
<br>
Об ограничении в 64k соединений в основном имеет смысл говорить при<br>
проксировании между одним фронтендом и одним бекендом.  Это как раз тот<br>
случай, когда src_ip - фиксирован.  Но это - совсем отдельный<br>
случай, хотя и важный.  И ограничение в 64k соединений в этом<br>
случае - легко обходится как добавлением ip-адресов бекенду, так и<br>
фронтенду.<br></blockquote><div><br></div><div>у меня 7 бекендов и 4 фронтенда, каждый из 4х связан с каждым из 7ми,  448к получается на каждом )<br><br></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>
<div class="im"><br>
> > В этом же треде мне недавно доказывали обратное:<br>
><br>
> А к чему вы тогда склоняетесь? К тому что написано в документации, или к<br>
> тому, что кто-то сказал в треде?<br>
> Я бы игнорировал замечания в треде, если они противоречат документации.<br>
> И заблуждению что keys_zone ограничивает максимальное кол-во ключей<br>
> вобщем-то даже объяснимо, т.к. действительно есть другие параметры, где<br>
> указанный размер косвенное ограничивает число ключей, хотя сначала все равно<br>
> фактический размер памяти.<br>
<br>
</div>Самокритично.  :)<br>
<br>
Документации (и реальности) противотиворечит ваше утверждение, что<br>
размер кеша на диске ограничивается параметром keys_zone.<br></blockquote><div><br></div><div>Весь прикол в том что реальности оно, вроде бы как, не противоречит. Если keys_zone больше max_size - то действительно кеш почему-то держится строго в рамках keys_zone. )<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>
Параметр keys_zone - не ограничивает размер кеша (на диске), он<br>
определяет размер области разделяемой памяти, которая отводится<br>
для хранения ключей (и соответственно косвенно определяет<br>
максимально возможное число ключей к кеше).<br>
<br>
<a href="http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_path" target="_blank">http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_path</a><br>
<div class="im"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.com/support.html" target="_blank">http://nginx.com/support.html</a><br>
<br>
</div><div class=""><div class="h5">_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></div></div></blockquote></div><br></div></div>