Как стать автором
Обновить

Кэширование данных, возможно последняя вещь которую Вам стоит использовать

Время на прочтение 3 мин
Количество просмотров 13K
Автор оригинала: Morgan Tocker
Недавно у меня был достаточно горячий конфликт с популярным PHP пакетом для электронной коммерции. В результате мне захотелось рассказать об одной распространенной ошибке в архитектуре веб приложений.

В чем же эта ошибка?


Пакет с которым я работал, интенсивно использовал кэширование. Он не мог отдавать более 10 страниц в секунду, если не были включены некоторые «опциональные» настройки кэша. Очевидно что с такой производительностью они на самом деле не опциональны, а обязательны.

Я думаю, что когда у Вас есть такой замечательный инструмент как memcached, так и хочется использовать его для решения любой проблемы с производительностью. Но во многих случаях он не должен быть первым инструментом который Вы пытаетесь использовать. И вот почему:

Кэширование может работать не для всех пользователей — Вы открываете страницу — она загружается быстро. Но так ли это для всех пользователей? Кэширование очень часто позволяет оптимизировать время загрузки для большинства посетителей, но часто в реальности Вам надо чтобы страница загружалась быстро для всех без исключения (если следовать принципу six sigma). На практике запрос может промахиваться мимо кэша всегда для одного и того же пользователя, что еще более усугубляет ситуацию (Прим. переводчика: Я знаю совершенно реальный случай, когда в электронном магазине кэш срабатывал для 99% процентов пользователей и не работал для 1% посетителей имевших длинную историю покупок, как результат магазин работал медленно как раз для активных покупателей).

Кэширование может уводить Вас в сторону от решения проблемы — Вы смотрите на наиболее медленно загружающуюся страницу и пытаетесь ее оптимизировать. Но хитрость здесь в том, что в реальности проблема с производительностью может лежать в другой области (опять six sigma). Вы «залечиваете» проблему кэшируя, например, страницу целиком, но сама проблема с производительностью никуда не уходит и остается скрытой (Прим. переводчика: с тем чтобы всплыть на других страницах еще и еще и еще раз).

Управление кэшем в реальности непростая задача — Вы когда-нибудь боролись с "убеганием кэша" или с ситуацией когда большое количество элементов кэша инвалидируются одновременно?

Альтернативный подход


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

Что это за способы?


Перед тем как вводить оптимизацию убедитесь что Вы прошлись по этому достаточно простому списку:

Вы понимаете план исполнения каждого запроса? Если нет, установите long_query_time=0 и используйте команду mk-query-digest, чтобы получить полный список запросов. Выполните для каждого из них EXPLAIN, проанализируйте план исполнения.

- Вы используете SELECT * чтобы потом использовать только небольшой набор столбцов? Или вы выбираете из БД много строк, но используете только некоторые из них? Если это так — то вы выбираете слишком много данных, ограничивая оптимизацию уровня СУБД, такую например как использование индексов.

Знаете ли Вы сколько именно запросов Вы используете для генерации одной страницы? Все ли они действительно необходимы? Можно ли какие-то из этих запросов превратить в один запрос или вообще убрать? (Прим. переводчика: Очень распространенная проблема. Реально знаю случай когда на странице отображался список учеников в классе, а затем в цикле для каждого ученика запрашивалась дополнительная информация, включая название класса. После переделки количество запросов сократилось с 61 до 3-х).

Думаю что как вывод можно сказать: «Оптимизация очень редко уменьшает сложность приложения. Старайтесь избегать усложнения, за счет оптимизации только того, что действительно надо оптимизировать» — цитата со слайда Джастина — instrumentation-for-php.

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

Прим. переводчика: Совершенно реальный диалог произошедший не так давно:
— Так у нас проблемы с производительностью, надо добавить кэширование, вертикальное партиционирование и NoSQL DB для логинов
— Парни — я тут посмотрел EXPLAIN — у Вас fullscan запрос на 4,000 строк, я попробовал создать индекс- все ускорилось в 26 раз.

Несколько замечаний к переводу

1. Термин cache stampeding — я перевел как убегание кэша (был соблазн перевести как «просрачивание», но это было бы неправильно). Если коротко, это ситуация, когда например определенный запрос выполняется достаточно долго и результаты этого запроса кэшируются, когда затем эти данные рано или поздно уходят из кэша, и одновременно рендерится 10 страниц на которых эти данные нужны, то в БД отправляется 10 медленных запрсов, вместо одного. Обычно с этим борются пере запрашивая данные до того как они будут выкинуты из кэша. см например
2. Хочу обратить внимание, что в статье не говорится что кэшировать данные не надо. Их надо кэшировать, но только после того как Вы попробуете несколько простых способов оптимизации запросов к БД. Иными словами начинать надо с простого.
Теги:
Хабы:
+42
Комментарии 58
Комментарии Комментарии 58

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн
PG Bootcamp 2024
Дата 16 апреля
Время 09:30 – 21:00
Место
Минск Онлайн
EvaConf 2024
Дата 16 апреля
Время 11:00 – 16:00
Место
Москва Онлайн