Недавно на консультации разработчик показывал HTTP-кэширование главной страницы. Мне сразу бросилось в глаза, что для проверки If-Modified-Since в базу делается целая пачка далеко не лёгких запросов с join-ами, которые выясняют, как давно изменялись сущности, участвующие в рендеринге. Я предложил проверить, действительно ли это быстрее, чем просто отдать страницу.
Пару лет назад в докладе Павла Паршикова я познакомился с формулой целесобразности кэширования:
rp + (r + c + w)(1 - p) < c
c — стоимость выполнения кэшируемой операции,
0 < p < 1 — вероятность попадания в кэш (hit),
r — стоимость чтения и валидации кэша,
w — стоимость записи в кэш.
После упрощения:
r + w(1 - p)
———————————— < c
p
Получается, что кэширование имеет смысл тогда, когда взаимодействие с ним обходится дёшево, а вероятность хита близка к 1.
Как правило, наибольшее внимание уделяют
p, подразумевая, что сам кэш достаточно быстрый. Но r не стоит недооценивать. В описанной в начале поста ситуации именно стоимость валидации оказалась слишком высокой, из-за чего кэширование потеряло смысл.