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
процентов страниц, которые все равно заэкспайрятся там после первой же
отдачи, чем разбираться - какие куки кэшировать, а какие нет.
> Игорь Сысоев
>
>
> =============================================================================
> = Apache-Talk@lists.lexa.ru mailing list =
> Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
> = Archive avaliable at =
>
--
Victor Wagner vitus@ice.ru
Chief Technical Officer Office:7-(095)-748-53-88
Communiware.Net Home: 7-(095)-135-46-61
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 =
