ПРОЕКТЫ 


  АРХИВ 


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: Вопросы по возможностям прокси



Hello!

On Thu, Jul 08, 2010 at 09:40:14PM -0400, Alexandr Sergeyev wrote:

> Про SSL я писал недавно, про кеш сессий в memcached похоже 
> планов нет. Спрошу тогда про прокси...

Вопрос с ssl-сессиями в memcached очень простой: зачем?  Есть 
мнение, что ходить в memcached за сессиями - будет дороже, чем 
устанавливать их заново.  Если кто-то считает иначе - пусть 
приводит хоть какие-то выкладки и результаты экспериментов под 
реальной нагрузкой.

А потом мы ему расскажем что в nginx'е держать keepalive ничего не 
стоит, что снижает ценность кеша ssl-сессий в разы по сравнению с 
Apache... ;)

> Очень интересно есть ли планы поддерживать RFC5861? В частности 
> 
> Cache-control: stale-if-error=timeout и
> Cache-control: stale-while-revalidate=timeout
> 
> Я понимаю что первое реализуется через proxy_cache_use_stale, а 
> вот второе было бы здорово иметь...

А второе - это proxy_cache_use_stale updating;.

> Стоит заметить что для вашей последней дискуссии про bypass 
> возможно подойдёт просто использование Cache-control: 
> only-if-cached или других из RFC2616, я не очень понял что к 
> чему с этим bypass.

Всё это "с этим bypass" - прямое следствие того, что 
"Cache-Control: no-cache" делает две принципиально разные вещи в 
разных направлениях.  А именно - не берёт из кеша, если этот 
заголовок получен в запросе, и не кладёт в кеш если этот заголовок 
получен в ответе.

"Cache-Control: only-if-cached" здесь ну совсем никоим боком.

[...]

> Ещё вопрос как прокси работает когда сразу сотня клиентов 
> запрашивают один и тот же ресурс доступный на бэкэнде... Есть ли 
> какой способ аналогичный collapsed_forwarding в squid сказать 
> "всем ждать пока первый не получит ответ"?

А это называется "busy lock'и", было ещё в mod_accel'е, в nginx'е 
пока не сделано и не совсем понятно когда будет сделано.  Но 
когда-нибудь вероятно всё-таки будет.  У большинства не болит, ибо 
есть тот самый proxy_cache_use_stale updating;.

> Если говорить о вкусностях подсмотреных в squid хочется 
> упомянуть ещё и "quick_abort", который говорит акселератору, что 
> при уходе клиента от фронтэнда кеш должен подождать если контент 
> уже начал приниматься от бэкэнда.

В nginx'е кеш автоматически включает логику аналогичную
proxy_ignore_client_abort.

Maxim Dounin

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


 




Copyright © Lexa Software, 1996-2009.