ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


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


  ПРОГРАММЫ 



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














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

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

Re: [apache-talk] =?koi8-r?B?68HLINPOxdPU?==?koi8-r?B?ySDL1cvVINDSySDJ09DPzNjaz9fBzsnJ?= mod_accel



On 2002.08.28 at 12:48:13 +0400, Igor Sysoev wrote:

> 
> AccelPassCookie нужен в том случае, если бэкенд умеет управлять
> кэшированием и поэтому на фронтенде лень выставлять в куче Location
> AccelCache on/off.

Что такое "бэкэнд умеет управлять кэшированием"? 
Если это значит "умеет ответить на запрос с If-Modified-Since
существенно быстрее чем сгенерировать страницу целиком", то наш - не
умеет. Ибо возможностей у разработчика шаблона повлиять на то, что
отдается в качестве  Last-Modified слишком много, чтобы это можно было
оценить иначе чем посредством интерпретации всего шаблона.

Если же под "умеет управлять" имеется в виду "генерируя данную
конкретную страницу может сказать, кэшировать ее или нет", то умеет.

> > Правильным с точки зрения такой задачи - минимизировать нагрузку на
> > бэкэнд, обеспечив при этом наиболее агрессивное кэширование при
> > максимальной прозрачности.
> 
> Set-Cookie в большинстве случаев - вещь сугубо индивидуальная.
> Хотя, вот один пример не инивидуальности я увидел - logout.

Для меня кука это такой Session-Persistent параметр запроса,
который от параметров, передаваемых методом GET отличается только
тем, что а) требует меньше траффика (не нужно его прописывать с каждую
URL на отдаваемой пользователем странице)
б) не мешается в строке URL. 

Т.е. подход, описанный в описании AccelCacheCookie, когда кука считается
частью кэшируемой URL, мне нравится.

Только еще хотелось бы, чтобы при отдаче страницы, в заголовке которой
содержится Set-Cookie, эта страница кэшировалась бы так, как будто этот
заголовок уже возымел действие. Т.е. ее ключ в кэше содержал бы те куки,
которые образовались бы в результате применения этого заголовка к тому
набору кук которые были присланы клиентом.

Отдача страницы, содержащей Set-Cookie с X-Accel-Expires: 0 кажется
разумным компромиссом между этим желаемым и имеющимся действительным.
В этом случае страница будет закэширована только тогда, когда за ней
придет клиент с тем набором кук, который имел в виду бэкэнд при ее
генерации.

> Кстати, ещё о кэшировании кук. Я считаю, что кэшировать их имеет
> смысл в случае 80/20, то есть, если 80% посетителей имеют одинаковый
> набор кук (в том числе не имеют их вообще), 20% - разный.
> 80 и 20 - условные цифры.

Исходя из Turing completeness бэкэнда кажется дешевле кэшировать 80
процентов страниц, которые все равно заэкспайрятся там после первой же
отдачи, чем разбираться - какие куки кэшировать, а какие нет. 


 
> Игорь Сысоев
> http://sysoev.ru
> 
> =============================================================================
> =               Apache-Talk@lists.lexa.ru mailing list                      =
> Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
> =       Archive avaliable at http://www.lexa.ru/apache-talk                 =
> 

-- 
Victor Wagner                   vitus@ice.ru
Chief Technical Officer         Office:7-(095)-748-53-88
Communiware.Net                 Home: 7-(095)-135-46-61
http://www.communiware.net      http://www.ice.ru/~vitus
=============================================================================
=               Apache-Talk@lists.lexa.ru mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =



 




Copyright © Lexa Software, 1996-2009.