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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

• Время загрузки JS:0.274
• Количество запросов:15
• Время загрузки PHP:0.0524
• Использование памяти:1.013 МБ

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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