Долгосрочное кеширование статических страниц

Когда вы говорите, что у вас нет данных, как вы вообще используете asp.net или C#. Какие функции это дает вам по сравнению с обычным HTML? Кроме того, если вы планируете кэширование, вероятно, лучше всего кэшировать файл, а затем, когда будет сделан запрос, передать файл в потоковом режиме. ОС позаботится о сохранении файла в памяти, чтобы вам не приходилось все время читать его с диска.

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

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

Если есть большие файлы, которые нужно кэшировать, я бы посмотрел, поддерживает ли ваш движок контента If-Modified-Since.

Для файлов меньшего размера (содержимое страницы, CSS, изображения и т. д.), Где уменьшение количества циклов приема-передачи является ключевым, наличие длительного срока хранения (год?) И изменение URL-адреса при изменении содержимого является лучшим. Это позволяет вам контролировать, когда пользовательские агенты будут получать новый контент.

Yahoo! опубликовали статью из двух частей о уменьшение HTTP-запросов и использование кеша браузера. Я не буду повторять все это здесь, но это хорошие статьи, которые подскажут, что делать.

Я считаю, что нужно выбрать период времени, достаточно высокий, чтобы охватить отдельные сеансы большинства пользователей, но достаточно низкий, чтобы не причинять слишком много неудобств, если вы захотите обновить контент. Обязательно поддерживайте If-Modified-Since, если у вас есть Last-Modified для всего вашего контента.

Наконец, если ваш контент вообще кэшируется и вам нужно отправить новый контент сейчас, вы всегда можете использовать новый URL-адрес. Этот окончательный URL-адрес кэшируемого содержимого может располагаться за фиксированным URL-адресом Перенаправление HTTP 302, если вы хотите опубликовать постоянную ссылку на последнюю версию.

У нас есть аналогичная проблема с проектом, над которым я работаю. Есть данные, которые являются статическими довольно много, но могут быть изменены.

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

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

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

Это могло быть совершенно неправильным способом сделать это, но, похоже, он работает для нас очень хорошо :)

Если он статический, вам, вероятно, будет лучше сгенерировать страницы один раз, а затем напрямую обработать полученный статический HTML-файл.

Если он статический, зачем вообще кешировать? Пусть об этом позаботится IIS.