Прежде всего, относительно ссылочной ссылки на блог Натанаэля Джонса, хотя дисковый ввод-вывод намного медленнее, чем в операциях с памятью, большинство веб-сайтов не связаны с дисковым вводом-выводом, и большинство его решений - откровенно необразованная хрень.
Вообще говоря, существует всего несколько ситуаций, в которых вы становитесь привязанными к DISK. Первый - это сам сервер базы данных. Если у него недостаточно ОЗУ для хранения соответствующих частей базы данных в памяти, тогда скорость диска ЭТОГО сервера имеет решающее значение; особенно в условиях высокой транзакции.
Во-вторых, вы можете связать дисковый ввод-вывод, если ваше приложение непосредственно читает и записывает много файлов. Очень мало приложений делают это. Я не считаю файлы .aspx или .html вашего приложения, потому что они могут быть кэшированы существующей структурой и IIS.
По сути, просто игнорируй его.
Идея синхронизации всей файловой системы с базой данных как метода повышения производительности не имеет значения для примерно 99,999% сайтов. Если ничего другого, база данных не должна передавать файлы в файловую систему веб-сервера, а не наоборот. Я видел ровно 1 сайт за 20 лет разработки, который требовал этого. Они обслуживают несколько миллионов просмотров страниц в день. Кроме того, он категорически ошибается, считая, что вызов базы данных по сети быстрее, чем загрузка эквивалентного объема данных из локального файла.
Далее, настоящая область, с которой мы действительно связаны, - это отправка данных по сети в браузер клиента. Это ВСЕГДА медленнее, чем чтение файла с диска; даже без трафика на линии. Жесткие диски перемещают данные намного быстрее, чем ваша сетевая карта. Сделать еще один шаг вперед; современные жесткие диски на несколько порядков быстрее вашего интернет-соединения. Лучшее, что вы можете сделать для повышения производительности, это просто ограничить количество запросов на соединение, необходимых для загрузки одной страницы. Оптимизация здесь означает наличие 1 файла CSS, а не 20; иметь только пару ссылок на файл .js, а не 100; и объединение графики в спрайты, где это возможно. Передача 1 большого файла быстрее, чем 100 маленьких, благодаря работе TCP.
Возможно, на перегруженном общем сервере у вас может быть проблема. Однако реальность такова, что перегруженный общий сервер будет перегружен сетью задолго до того, как длина очереди диска выйдет из-под контроля.
Учитывая это, давайте посмотрим на вашу реальную проблему.
Элементы javascript имеют два предпочтительных местоположения: 1. как файлы .js на веб-сервере или 2. встроенные в главную страницу. Просто сделайте вариант 1, они будут кэшироваться веб-сервером. Кроме того, они будут кэшироваться клиентским браузером, что означает, что вам не нужно
Для вашего верхнего и нижнего колонтитула код этого должен быть на вашей главной странице. Не делайте серверных включений, которые только усложняют вещи. Создайте нормальный веб-сайт .net, который использует главные страницы для вашего «хромированного» контента. Вы можете включить частичное кэширование страниц на уровне приложения, которое будет обрабатывать все кэширование для вас.
При обновлении содержимого верхнего или нижнего колонтитула просто повторно разверните сайт.