Какую информацию нужно кэшировать? Какое хорошее время загрузки страницы? - PullRequest
6 голосов
/ 20 октября 2008

Я нахожусь в процессе разработки сайта социальной сети.

И с самого первого дня работы над проектом я думал о масштабируемости, я прекрасно настроил сайт и делал запросы в меру своих возможностей.

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

Но не совсем уверен, что я должен кешировать, а не кешировать. Или, если текущее время загрузки страницы в 1 секунду хорошее или плохое.

Самым тяжелым запросом является сбор информации об участнике. Этот запрос получает всю информацию об участнике и все, что с ним связано, например, его цели, записи о типах блогов, поощрения, фотографии, обновления статуса (например, Twitter), информацию о блоге (для кросспостинг их записей) и т. д.

В любом случае, я должен кешировать эту информацию? Как вы думаете, время загрузки страницы в 1 секунду достаточно быстрое? Некоторые страницы занимают менее 4–10 секунд за секунду.

Ответы [ 6 ]

2 голосов
/ 20 октября 2008

Я бы реализовал кэширование на каждом уровне вашего приложения, если это вообще возможно.

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

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

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

2 голосов
/ 20 октября 2008

Типичный ответ:

  • Информация о кеше, которая редко обновляется.
  • Не кэшируйте то, что часто меняется.

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

Теперь о времени загрузки (которое может сильно различаться в зависимости от местоположения пользователя), вот некоторые информативные цифры с PHP-форума игрового сайта:

  • JS Время загрузки: 0,274
  • Количество запросов: 15
  • PHP Время загрузки: 0,0524
  • Использование памяти: 1,013 МБ

И это считается обществом хорошим опытом. Но это ужасно субъективно.

1 голос
/ 20 октября 2008

Для данных, относящихся к профилю пользователя, храните как можно больше в билете / cookie FormsAuth. Для кэширования (HttpContext.Current.Cache) пользовательских элементов потребуются ресурсы X на вашем сервере для каждого пользователя, так же, как для сеанса (но с меньшей головной болью). Если вы сможете как можно больше разгрузить пользовательский билет или файл cookie (например, 4K), тогда вы действительно увеличите производительность своих серверов при масштабировании.

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

Убедитесь, что вы понимаете, что существуют различия между кэшированием запросов базы данных (повторное использование плана выполнения), кэшированием объектов (Httpcontext.Cache) и кэшированием страниц (Response.Headers [Expires]).

1 голос
/ 20 октября 2008

Вопрос о загрузке страницы уже задан:

Что считается хорошим временем отклика для динамического персонализированного веб-приложения?

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

0 голосов
/ 20 октября 2008

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

0 голосов
/ 20 октября 2008

Гуру веб-дизайна Винсент Фландерс предполагает, что загрузка веб-страницы занимает более 4 секунд. Я думаю, что это довольно хорошее эмпирическое правило.

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

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

Я бы оставил это простым, и рефакторинг для производительности только там, где это необходимо.

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

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