Справочная информация: Репликация файла хромает
В настоящее время у нас имеется огромное высокопроизводительное веб-приложение ASP.NET с высокой нагрузкой, сбалансированное по нагрузке на 8 различных серверах IIS. Из-за особенностей сайта небольшие изменения в файлах .aspx и элементах управления .ascx часто происходят в течение дня, а после тестирования и публикации для использования реплицируются на каждый общедоступный веб-сервер посредством развертывания xcopy по расписанию каждый 10 минут.
Конечно, это невероятно неэффективно, поскольку на каждом сервере должна быть избыточная копия всего сайта, и мы хотели бы устранить 10-минутную задержку публикации.
Возможное улучшение: хостинг из общего хранилища
Теперь у нас есть возможность использовать централизованное хранилище с интерфейсом iSCSI для централизованного размещения всего сайта, при этом каждый сервер полагает, что удаленное хранилище является локальным диском. Публикации будут мгновенными и общесистемными.
Примечание. Размещение диска вне общего ресурса UNC невозможно, так как в структуре сайта так много разных каталогов, для каждого из которых требуется, чтобы FileSystemWatcher для ASP.NET отслеживал изменения, чтобы максимальное число команд SMB быстро достигается. Да, мы знаем о настройках реестра MaxCmds и MaxMpxCt.
Проблема: изменения в Web.config вызывают массовую перекомпиляцию
Проблема, которую мы ожидаем, состоит в том, что определенные изменения в структуре файловой системы могут привести к тому, что почти каждый скомпилированный файл .aspx или .ascx придется перекомпилировать, вызывая запросы в очереди и ощущение, что сервер не работает. Большинство ресурсов не используются в масштабе всей системы, поэтому их перекомпиляция при изменениях едва ли приводит к перебою в ресурсах. Это может быть вызвано глобальной главной страницей, используемой всеми страницами сайта, но это легко можно исправить с помощью кода.
Основной виновник - файл web.config. Изменения в файле web.config приводят к перезапуску всего веб-приложения и возникновению перекомпиляции. Таким образом, в настоящее время мы не реплицируем изменения web.config. Любые изменения web.config требуют отключения веб-сервера от балансировщика нагрузки, применения (и тестирования) изменений, а затем прогрева сервера с ненужными запросами перед его возвратом на балансировщик нагрузки.
Однако, если файл web.config, как и остальная часть структуры каталогов веб-приложения, расположен в централизованном хранилище, существует только одна копия файла, и отдельные серверы больше не могут быть исправлены и разогреты.
Вопрос
Есть ли способ заставить веб-приложение ASP.NET получать заказы на марширование из источника, отличного от файла с именем Web.config?
В идеале на сервере должен быть один файл, например:
- default.aspx
- global.asax
- Web-ServerA.config
- Web-ServerB.config
- ...
- Web-ServerN.config
Где в любом случае определено имя "web.config"? Есть ли параметр реестра, который можно установить для каждого сервера? Есть ли запись, которую можно сделать в machine.config или глобальном web.config, чтобы указать, какой файл использовать?
Что выходит за рамки
Просто, чтобы я понял, я не спрашиваю, как использовать разные AppSettings для отладки, тестирования и работы. Есть и другие темы, которые касаются этого, и все мои web.configs большую часть времени будут идентичны, единственное время, когда мне нужно, чтобы они отличались, это когда выполняется обновление.
Мы не используем web.config для каких-либо настроек приложения; это для действительно важных вещей, таких как ссылки на сборки, определения httpHandler и другие настройки system.web, которые не могут быть основаны на данных.
Обновление
Я попытался найти в реестре файл Web.config и не нашел ничего, кроме приложений, в которых отмечалось, что я недавно отредактировал файлы web.config, что я, по-видимому, и делаю много. Там нет никакой помощи.