Кэширование запросов к страницам поиска.

[Vano]

Стоит ли кэшировать всю страницу, если есть куча критериев поиска?
Или подскажите как вы кэшируете ответы страниц поиска.

 

[Vano]

Может есть смысл выключать кэш, если поиск идет по вручную введенными данными пользователя (таких как введенное в текс инпут имя к примеру), а в случае если трогались только критерии, которые можно выбрать из списка оставить кэш(так как их не так уж и много)

 

[grigori]

перенес

 

[AnrDaemon]

А что, кто-то ещё кеширует страницы целиком?…

 

[Vano]

Уверен, везде где это возможно - 100% стоит кэшировать страницы целиком

 

[c0dex]

@Vano, ну кешируй Как только решишь вопрос инвалидации такого кеша, с часто изменяющимися динамическими данными - приходи и делись наработками.

 

[Vano]

Так. Пример 1: Кэшируем страницу какой-нибудь новости. Можно? Легко - зависимость актуальности такой странцы будет дата последнего обновления статьи в БД. Нужно? Давайте посмотрим:
Выборка с БД - 20мс; Постройка страницы 300мс; в браузере ответ возвращается за 390мс
Закэшировал - в браузере ответ возвращается за 130мс.
Думаю стоит того. Надеюсь с этим все согласны.

Пример 2, с которым я еще не решился что делать: Раздел поиска. Ищем пользователей с ихними профилями. На странице 20 профилей. Критериев поиска 5, и все они из списка (тоесть каждый критерий имеет 5 вариантов к примеру, допустим "женат" да/нет; "есть дети" да/нет, "тип пользователя" первый/второй/третий/четвертый ...)

Пример 3, тот же пример 2, но есть критерии поиска вводимый конечным пользователем (к примеру поиск по имени или фамилии)

Вот не знаю что делать с примерами 1, 2. Были бы статические данные то 100% кэшировал бы навсегда каждый гет запрос.
И еще пища для размышления. Если постройка страницы занимает намного больше времени чем выборка из БД, то не стоит ли кэшировать всю страницу с зависимостью актуальности такого кэша (SELECT max(updated_at) <строка генерируемая в зависимости от ГЕТ запроса>)

 

[c0dex]

Так. Пример 1: Кэшируем страницу какой-нибудь новости. Можно? Легко - зависимость актуальности такой странцы будет дата последнего обновления статьи в БД. Нужно? Давайте посмотрим:
Выборка с БД - 20мс; Постройка страницы 300мс; в браузере ответ возвращается за 390мс
Закэшировал - в браузере ответ возвращается за 130мс.
Думаю стоит того. Надеюсь с этим все согласны.

Неа, не согласен. Время трансфера ответа от сервера к клиенту будет одинаковым в любом случае. И да, актуальность такой страницы равна нулю. Если на ней есть динамика. К примеру список последних новостей. Ведь ты не оспоришь факта того, что у тебя может добавиться какая-то новость после той, которую ты захотел закешировать и настранице тогда она уже не покажется. Пример высосан с пальца, но показывает направление мысли.

 

[Vano]

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

 

[AnrDaemon]

То есть уже не целиком?…

 

[Vano]

В MVC этот кусок будет либо виджетом (выборка из БД произойдет внутри кода виджета) или отдельным аякс запросом.

 

[Vano]

На худой конец! на худой, кэшировать можно по 1 или 5 минут, без условия актуальности страницы. Просто данные иногда будут опаздывать на 5 минут.

 

[c0dex]

Начинаешь придумывать обходные пути? Это хорошо) Но лучше все таки на первом этапе кешировать данные по выборкам из БД и прочих узких мест.

 

[Breeze]

Неа, не согласен. Время трансфера ответа от сервера к клиенту будет одинаковым в любом случае. И да, актуальность такой страницы равна нулю. Если на ней есть динамика. К примеру список последних новостей. Ведь ты не оспоришь факта того, что у тебя может добавиться какая-то новость после той, которую ты захотел закешировать и настранице тогда она уже не покажется. Пример высосан с пальца, но показывает направление мысли.

кстати для новостного ресурса подход "кеширую целиком" вполне себе работает

 

[c0dex]

@Breeze, не всегда, хотя можно поднять кеш прямо на nginx. Вопрос только в актуальности данных от времени. В любом случае - полное кеширование не его вариант пока что. Хотя пример с новостями немного кривоват вышел, да =(

 

[Vano]

Начинаешь придумывать обходные пути? Это хорошо) Но лучше все таки на первом этапе кешировать данные по выборкам из БД и прочих узких мест.

Ну как по выборке из БД? всмысле кэшировать результат выборки из бд?

 

[Breeze]

@Breeze, не всегда, хотя можно поднять кеш прямо на nginx. Вопрос только в актуальности данных от времени. В любом случае - полное кеширование не его вариант пока что. Хотя пример с новостями немного кривоват вышел, да =(

да и с nginx норм 2-3 минуты, если редакцию устраивает.
а так сложный ключ с тегами и версионностью делает обновление кеша практически в реалтайме.

 

[c0dex]

Ну как по выборке из БД? всмысле кэшировать результат выборки из бд?

Всмысле да.

 

[Breeze]

Ну как по выборке из БД? всмысле кэшировать результат выборки из бд?

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

 

[AnrDaemon]

Кешировать отдельные блоки структуры (результат выборки, уже отрендеренный для показа) и собирать из них страницу налету.
Так у тебя разное время кэша для разных блоков (динамику хоть вообще не кешируй), и вменяемое время ответа сервера. Если клиентов становится совсем много, и движок начинает загибаться, ставишь фронт кэш на 5 секунд. Это при условии, что на странице нет элементов, чувствительных к безопасности.
Вообще, товарищи, ставящие full page cache, часто забывают о том, что далко не всегда одна страница устроит всех клиентов. А делать кэш пер-юзер - это уже не кеш, это уже извращение.