Блог: Кэширование

ЗЫЖ Либо кэширование будет производится исключительно в Application Server, а значит будет менее эффективно.

Имхо нет ничего страшного если в нескольких процентах случаев процесс будет доходить до AppServer, это уже вопрос балланса между этими процентами и общей загруженностью (интеллектуальностью) фронта. Не исключено что даже от простого и достаточного быстрого варианта работы фронта следует отказаться в пользу совсем примитивного (и совсем скоростного), если последнего достаточно в 99% случаев

Тут главное, чтобы "нет ничего страшного" не трактовалось не правильно: между "в принципе возможно, но сложно" и "невозможно" очень большая разница.

А ещё весь креатифф маркетологов должен проходит через фильтр "возможности закэшировать". Особенно это касается высоко-нагруженных проектов.

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

это я писал на самом деле

А я как раз ставлю под сомнение "абсолютную правильность" креативов. Часто именно эти креативы нельзя пропускать дальше по тех.процессу не изменив детали.

ну это и есть процесс проектирования

Кстати говоря, если всё вышесказанное труЪ, то возникает вопрос, а что же такое "запрос клиента" ?
И весь вопрос сводится к тому, что нужно положить в куки, чтобы на сервере можно было однозначно вычислить ключ для memcached. И мы опять возвращаемся к ролям юзверя на сайте (правда уже в упрощённом варианте).

да, нужно определить "человеческие" критерии что нужно кэшировать и что не нужно, т.е. не опираясь на то или иное представление о внутренней кухне.

Не! Диман, кэшировать нужно всё =) Но, т.к. это не возможно, важно продумать содержимое куков в запросе для повышения вероятности кэширования ответа сервера.

вероятность кэширования не самый важный показатель, куда важнее вероятность попадания в кэш, т.е. наличия нужного объекта в кэше. Даже если нет TTL, есть ограниченный объем памяти/места кэш-провайдера, как следствие есть evictions (осмысленные жертвы, удаление старого или редкопользуемого для высвобождения места под новое), а это значит, что запрос редкий сам по себе может не будет обрабатываться через кэш, а проверка кэша будет все равно.

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

з.з.ы. можно поступить формально, все посчитать:
Допустим простой фронт обрабатывает запрос с кэшем за 0.01 с
Бэк (тоже имеет кэширование) обрабатывает за 0.1 с
Сложный фронт - за 0.02 с

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