ASP.NET: доступ к файлам aspx / ascx с диска при каждом запросе? - PullRequest
0 голосов
/ 08 июня 2011

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

Я спорил с кем-то, кто настаивал на кэшировании некоторых статических файлов на сайте ASP.NET, где я думал, что нет необходимости из-за простого факта, что все другие файлы, которые генерируют динамический HTML, не кэшируются (по умолчанию; давайте пока не обращайте внимания на кэширование вывода; давайте также проигнорируем механизм кэширования, который имел в виду человек (в памяти или вне сети)). Другими словами, зачем кешировать какой-нибудь xml-файл (независимо от того, как часто к нему обращаются), когда все aspx-файлы читаются с диска при каждом запросе, который отображается на них? Если я прав, за счет кэширования таких статических файлов будет получено очень мало (меньше операций чтения с диска), но будет потрачено больше памяти (если кэшировано в памяти) или будет вызвано больше сетевых операций (если кэшируется на внешней машине) , Кто-нибудь знает, что на самом деле происходит, когда [обычно] запрашивается файл aspx? Спасибо.

Ответы [ 3 ]

0 голосов
/ 08 июня 2011

Если я не ошибаюсь, ASPX-файлы компилируются во время выполнения при первом доступе.После того, как страница скомпилирована в экземпляр класса Page в памяти, запросы к тому же ресурсу (странице ASPX) обслуживаются для объекта в памяти.По сути, они кэшируются относительно доступа к диску.

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

Что касается потребления памяти в зависимости от времени доступа к диску, я должен сказать, что с точки зрения производительности он делаетсмысл хранить объекты в памяти, а не читать их с диска каждый раз, когда они используются часто.Доступ к диску на 2 порядка медленнее, чем доступ в ОЗУ.Хотя неправильные стратегии кэширования могут вытолкнуть часто используемые объекты из памяти, чтобы освободить место для редко используемых объектов, что может привести к снижению производительности по очевидным причинам.При этом кеширование действительно важно для высокопроизводительного веб-сайта или веб-приложения.

В качестве обновления учтите следующее:

  • Типичное время доступа к DRAM составляет от 50 до 200 нано-секунды
  • Среднее время доступа к диску находится в диапазоне 10 - 20 миллисекунд

Это означает, что без кэширования попадание на диск будет в ~ 200 раз медленнее, чем доступ к ОЗУ.Конечно, операционная система, жесткий диск и возможные другие компоненты между ними могут выполнять свое собственное кэширование, поэтому замедление может произойти только при первом обращении, если у вас есть только пара таких файлов, с которых вы читаете.

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

0 голосов
/ 08 июня 2011

Я полагаю, что ответ на ваш вопрос зависит как от используемой версии IIS, так и от настроек конфигурации.

Но я считаю, что можно настроить некоторые комбинации IIS / .Net, чтобы избежать проверки файлов - есть опция для предварительной компиляции сайтов , поэтому никакой код на самом деле развертывать не нужнона веб-сервер.

0 голосов
/ 08 июня 2011

IIS выполняет большой объем кэширования, поэтому напрямую нет. Но IIS проверяет ЛЮБЫЕ изменения в веб-каталоге и перезагружает любые измененные файлы по мере их изменения. Иногда IIS блокируется, и вам нужно перезапустить его, чтобы обнаружить изменения, но обычно он работает довольно хорошо.

P.S. Механизмы кэширования могут часто сбрасывать данные в зависимости от использования сервера, но кэширование работает для всех файлов в веб-каталоге. Любые обнаруженные изменения в исходном коде приводят к тому, что IIS сбрасывает веб-приложение и перекомпилирует / перезагружает его.

...