Кэширование это хорошая идея?Если да, то где? - PullRequest
2 голосов
/ 05 апреля 2011

У меня есть веб-сайт asp.net с 10-25 тысячами посетителей в день (пики более 60 тысяч перед праздниками).Страницы / посещения также высоки, так как это контент-сайт.У меня есть несколько конкретных страниц, которые генерируют около 60% трафика.Эти страницы немного сложны и имеют большой объем базы данных (SQL Server 2008 r2 backend).Мне было интересно, стоит ли «кэшировать» статическую версию этих страниц (я слышал, что это возможно) и перерисовывать их только тогда, когда что-то меняется (примерно раз в 48 часов).Это звучит как хорошая идея?Где будет лучшее место для реализации этого?(asp.net, iis, db)

Обновление: Похоже, хорошим вариантом для меня является выходной кэш с SqlDependency.Я вижу ссылку на какое-то уведомление SQL-сервера о признании недействительным кэша, но я вижу только разговоры о SQL-сервере 2005. Не рекомендована ли Microsoft эта опция?Есть новый способ справиться с этим?

Ответы [ 3 ]

2 голосов
/ 05 апреля 2011

Кэширование - это широкий термин, который может встречаться в разных местах.Оптимальное решение может быть комбинацией некоторых или всех.

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

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

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

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

1 голос
/ 21 января 2013

Кэширование может или не может помочь.Например, если у сайта низкий трафик и если включено кэширование, сервер обрабатывает создание кэша перед обработкой запроса.А поскольку трафик низкий, между последовательными запросами может быть достаточно задержки.Таким образом, кэшированная версия может даже устареть, и сервер снова создает новую кэшированную версию.Этот процесс делает ответ даже медленнее, чем обычно.Подробнее о: http://tipscow.com/caching-the-good-the-bad/

Я сам сталкивался с этой проблемой.

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

1 голос
/ 05 апреля 2011

У меня нет большого опыта в кешировании, но я бы попробовал:

  • Я бы посмотрел вашу статистику и запустил несколько профилей, чтобы увидеть, какие страницы наиболее часто посещаются и на которых выполняются самые дорогие запросы SQL. Выберите одну или две самые дорогие страницы.

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

  • Если на странице есть динамическое содержимое в реальном времени, например комментарии, вы можете идентифицировать статические элементы управления и кэшировать их по отдельности. Не включайте кеш на всю страницу.

Удачи, похоже, что кеш может улучшить производительность.

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