Проблема с кешированием в javascript и asp.net

Question

Я задал здесь вопрос относительно кэширования данных для веб-приложения календаря / планирования и получил несколько хороших ответов. Однако теперь я решил изменить свой подход и статистику кэширования данных в javascript.

Я непосредственно кеширую HTML для каждого столбца дня в сетке календаря внутри объекта $ ('body'). Data (), который дает очень быстрое время загрузки страницы (почти незаметно).

Однако проблемы начинают возникать, когда пользователь запрашивает данные, которых еще нет в кэше. Эти данные создаются сервером с помощью ajax-вызова, поэтому они асинхронные и занимают около 0,2 с за неделю.

Мой нынешний подход заключается в простом блокировании на 0,5 с, когда пользователь запрашивает информацию с сервера, и кэшировании 4 недель с обеих сторон в начальной загрузке страницы (и 1 дополнительной недели на запрос на изменение страницы), однако я сомневаюсь, что это оптимальный метод.

У кого-нибудь есть предложения по улучшению ситуации?

Подведем итог:

• Каждую неделю для получения с сервера асинхронно требуется 0,2 с.
• Производительность должна быть как можно ближе к реальному времени. (однако данные не обязательно должны быть полностью в режиме реального времени: большинство встреч добавляются пользователем, и после этого мы можем повторно кэшировать их)
• В настоящее время 4 недели кэшируются по обе стороны от начальной загрузки: этого недостаточно.
• для кэширования 1 год занимает ~ 21 с, это слишком медленно для начальной загрузки.

Answer 1

Когда я читал ваше описание, я подумал о двух вещах: асинхронность и кэширование.

Во-первых, асинхронность

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

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

Интеллектуальное кэширование

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

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