LINUX.ORG.RU

Кэширование


0

0

Поиски не дали исчерпывающего ответа на вопрос, как правильно и эффективно реализовать кэширование сайта. Нашёл, что недавно nginx научился кэшировать ответ бэкенда. В принципе подходит, но хочу всё же уточнить и спросить совета.

Что имеется: сайт на Tomcat-е. Пока им отдаётся и динамика, и статика. Динамика генерится тяжело, запросы к БД и их обработка. Небольшой "тюнинг" БД и самого Томката сделал, большого прироста скорости не дало.

Чего хочется: поставить перед ним nginx, настроить через него отдачу статики, за динамическим контентом отправлять к томкату, ответ кэшировать. При первом же POST-запросе сбрасывать весь кэш (для простоты, это не страшно, т.к. изменения будут нечасто, но было бы неплохо указать для некоторых URL, что их кэшировать вообще не надо, но думаю, что это возможно).

Буду рад вашему мнению по поводу того, правильно ли я вообще собираюсь организовать всё это? Какие подводные камни? Где можно почитать по этой теме ?

★★★★★

> При первом же POST-запросе сбрасывать весь кэш

в чем профит от использования кеша, который а) сбрасывается так часто, б) сбрасывается целиком?

научись из самого приложения возвращать HTTP-заголовки Expires и Last-Modified, что бы кеширующий веб-сервер мог хоть как-то ориентироваться.

oc
()
Ответ на: комментарий от oc

Изменение данных на сайте происходит максимум раз в день, обращений в день к сайту несколько десятков тысяч запросов, каждый запрос обрабатывается около 4 секунд. По-моему профит очевиден, даже при полном сбросе кэша раз в день, будет сэкономлено много минут ожиданий пользователей.

Я не писал, что могу модифицировать приложение, выполняющееся на бэкенде.

roy ★★★★★
() автор топика
Ответ на: комментарий от commit

А чем его использование лучше nginx? Со сквидом работал только в режиме обычного прокси, с nginx вообще ещё никак :)

roy ★★★★★
() автор топика
Ответ на: комментарий от roy

Чем лучше или хуже? Не имею понятия. Не сравнивали ещё.

commit ★★
()

народ вон Апач в качестве прокси хвалит... сам не пробовал, ничего конкретного сказать не могу.

isden ★★★★★
()

Меня больше интересует вопрос: как сбросить кэш средствами прокси после получения POST-запроса? Из того, что прочитал, пока понял, что ключи в кэше либо устаревают, и замещаются новыми, либо бэкенд должен как-то сказать фронтенду, что надо обновить такой-то ключ. Как это сделать пока не понял.

roy ★★★★★
() автор топика
Ответ на: комментарий от roy

В том-то и соль, что такая задача решается на application layer, тобишь в приложении. Такого из коробки нет.

oc
()
Ответ на: комментарий от roy

> бэкенд должен как-то сказать фронтенду, что надо обновить такой-то ключ

Про какой кеш читал? Просто по описанию очень похоже на memcached, но вроде мы пока говорим о http proxy и кеше на диске, либо я не понимаю о каких "ключах" идет речь.

oc
()
Ответ на: комментарий от true_admin

А в наше время для каждой задачи был свой инструмент. Я жутко рад за нгинск что он начал уметь, но мы в началае 21 века тоже самое делали с oops и проблем не знали.

А как принудительно сбросить весь кеш? ТС спрашивал об этом.

oc
()
Ответ на: комментарий от true_admin

И в какой такой волшебнйо версии появилось кеширвание? на Debian Lenny шлет со всем директивами proxy_cache* - как-то не хорошо получается

oc
()
Ответ на: комментарий от true_admin

Ну хорошо, скомпилял я 0.7.63, перезапустил. Работает, все бы очень хорошо, но как бы сделать так как просил ТС - сбрасывать ключ при POST-запросе (авторизация, logout, размещения комментария), что бы сразу видеть результат. Иначе на динамическом сайте IRL малоприменимо.

Или хотя бы не отдавать кеш авторизованным пользователей. Такое возможно?

oc
()
Ответ на: комментарий от oc

> Или хотя бы не отдавать кеш авторизованным пользователей. Такое возможно?

Думаю, можно. Например, через задание правильного cache_key. Спроси в рассылке.

Имхо движок сайта должен кэшировать сам и только то что нужно и как нужно. Кэширование на nginx это, пока к нему не прикрутили api для управления кэшем, костыль.

true_admin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.