Какова правильная информация для кеша? Какое хорошее время загрузки страницы?

Question

Я занимаюсь разработкой сайта социальной сети.

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

Страница загрузки вопрос уже был задан вопрос:

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

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

Answer 3

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

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

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

Answer 4

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

• информация Cache, которая редко обновляется.
• Не храните то, что часто меняется.

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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