Когда / что кешировать в Rails 3 - PullRequest
4 голосов
/ 21 октября 2011

Кэширование - это то, что я как бы долго игнорировал, так как проекты, над которыми я работал, были в локальных интранетах с очень малой активностью. Сейчас я работаю над гораздо большим личным проектом Rails 3 и пытаюсь понять, что и когда мне следует кэшировать.

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

Руководства по Ruby on Rails прекрасно объяснили, как работает кэширование в Rails 3, но у меня возникают проблемы с пониманием процесса принятия решений, связанного с ним.

Ответы [ 3 ]

2 голосов
/ 21 октября 2011

Вам захочется подумать о кешировании нескольких видов вещей:

  • Запросы, которые сильно поражены и редко меняются
  • Запросы, которые «дороги» для рисованиямного обращений к базе данных и т. д. Также, надеюсь, они редко меняются.

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

Что касается фрагментации против полного кэширования страниц, подумайте о том, какчасто эти части обновляются.Если 3 части страницы никогда не обновляются, и одна из них, возможно, вы хотите кешировать эти 3, и разрешить выборку этой 1 в реальном времени, чтобы вы могли иметь точность до второй.Или, если разные части страницы должны иметь разные правила кэширования: возможно, раздел «временной шкалы» кэшируется, но имеет срок хранения 1 минуту.В то время как часть «друзей» кэшируется в течение 12 часов.

Надеюсь, это поможет!

2 голосов
/ 21 октября 2011

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

Прежде чем вы даже подумаете о кешировании, первое, что вы делаете, просматриваете ваше приложение для запросов, которые занимают больше всего времени.Не самые медленные запросы, но те запросы, которые ваше приложение тратит на наибольшее время.То есть, если у вас есть запрос A, который выполняется 10 раз при 1500 мс, и запрос B, который выполняется 5000 раз при 250 мс, вы сначала работаете над оптимизацией B.

На самом деле довольно просто grep через production.log иизвлекать время рендеринга и URL, чтобы объединить их в простой отчет.Вы даже можете сделать это в режиме реального времени, если хотите.

После того, как вы определили проблемный запрос, вы продолжаете разбирать, что он делает для обслуживания запроса.Во-первых, нужно искать любые запросы, которые можно объединить, используя энергичную загрузку или забегая вперед, чтобы предугадать, что вам нужно.Следующее - убедиться, что вы не загружаете неиспользуемые данные.

Сколько раз вы будете видеть код для перечисления пользователей, и он загружает 50 КБ на человека биографических данных, их ручек в Facebook и Twitterбуквально все о них, и все, что вы используете, - это их имя.Используйте connection.select_rows, когда вам не нужны модели.

Следующий шаг - посмотреть, какие запросы вы выполняете и как они не выполняются.Убедитесь, что все ваши индексы установлены правильно и используются.Убедитесь, что вы не выполняете сложные JOIN операции, которые могут быть решены с помощью некоторой тактической ненормализации.

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

Затем перейдите и посмотрите, как настроен ваш сервер базы данных.У него достаточно большие буферы?Это на аппаратном обеспечении, которое можно было бы обновить до большего объема памяти по номинальной стоимости?Слишком много людей используют полностью ненастроенный сервер баз данных и с несколькими простыми настройками они могут получить десятикратное увеличение производительности.

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

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

2 голосов
/ 21 октября 2011

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

Обычно, если для выполнения чего-либо требуется 500 мс, вам следует кэшировать, а если это более 1 секунды, вы, вероятно, делаете слишком много в запросе, и вам следует обрабатывать все, что вы делаете, в фоновом процессе… для Например, загрузка канала Twitter или манипулирование изображениями.

РЕДАКТИРОВАТЬ: См. Ответ apneadiving тоже , он ссылается на некоторые отличные скринкасты (хотя и на основе Rails 2, но теория та же.)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...