ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: помогите понять логику кеширования и буферизации






30 января 2013 г., 19:30 пользователь Maxim Dounin <mdounin@xxxxxxxxxx> написал:
Hello!

On Wed, Jan 30, 2013 at 05:51:25AM -0500, teo wrote:

[...]

> ... и максимальном кол-ве запросов на одном IPv4 в 65536 ...

Безотносительно к остальному тексту - вот это вот достаточно
частно встречающееся заблуждение, поэтому слегка потопчусь, дабы
развеять/прояснить.

Нет ограничения в 64k соединений на адрес.  Есть ограничение
уникальность комбинации src_ip:src_port:dst_ip:dst_port.  И из него
следует, что при фиксированных dst_ip, dst_port (т.е. ip сервера,
и порт 80) - остаётся два свободных параметра, src_ip и src_port.

Если мы зафиксируем вдобавок ещё и src_ip - то, действительно, у
нас останется для варьирования только src_port, и больше 64k
соединенией никак не открыть.  Но - это так только при
фиксированном src_ip, т.е. от _одного_ клиента.

Если же клиентов много (а у типичного веб-сервера их много) - то
соединений может быть сколько угодно (до 64k от каждого клиента).

Об ограничении в 64k соединений в основном имеет смысл говорить при
проксировании между одним фронтендом и одним бекендом.  Это как раз тот
случай, когда src_ip - фиксирован.  Но это - совсем отдельный
случай, хотя и важный.  И ограничение в 64k соединений в этом
случае - легко обходится как добавлением ip-адресов бекенду, так и
фронтенду.

у меня 7 бекендов и 4 фронтенда, каждый из 4х связан с каждым из 7ми,  448к получается на каждом )


[...]

> > В этом же треде мне недавно доказывали обратное:
>
> А к чему вы тогда склоняетесь? К тому что написано в документации, или к
> тому, что кто-то сказал в треде?
> Я бы игнорировал замечания в треде, если они противоречат документации.
> И заблуждению что keys_zone ограничивает максимальное кол-во ключей
> вобщем-то даже объяснимо, т.к. действительно есть другие параметры, где
> указанный размер косвенное ограничивает число ключей, хотя сначала все равно
> фактический размер памяти.

Самокритично.  :)

Документации (и реальности) противотиворечит ваше утверждение, что
размер кеша на диске ограничивается параметром keys_zone.

Весь прикол в том что реальности оно, вроде бы как, не противоречит. Если keys_zone больше max_size - то действительно кеш почему-то держится строго в рамках keys_zone. )
 

Параметр keys_zone - не ограничивает размер кеша (на диске), он
определяет размер области разделяемой памяти, которая отводится
для хранения ключей (и соответственно косвенно определяет
максимально возможное число ключей к кеше).

http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_path
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.