Сайт IIS на UNC-ресурсе: это проблематично?
Я работаю с устаревшим решением ASP Classic, которое сбалансировано по нагрузке (через внешнее оборудование и имеет сайт IIS, домашний каталог которого является UNC-путем. Мне сказали, что в настоящее время существуют следующие проблемы с этой настройкой:
- При использовании пути UNC в качестве домашнего каталога где-то в IIS есть «индекс», который «кэширует» до определенного количества файлов определенных типов, и когда предел, который по умолчанию равен 50, был достигнут, последующие запросы к страницы, которых нет в кеше, вернут 404.
- При использовании пути UNC в качестве домашнего каталога при запуске сайта IIS вышеупомянутый «кеш» начнет заполняться, что приведет к остановке IIS сайта до тех пор, пока кеш не будет заполнен, а это означает, что огромные сайты (15 000 файлов .asp) будут недоступны для до 30 минут после запуска сайта IIS.
- При использовании UNC-пути в качестве домашнего каталога, если к сайту поступает более определенного количества одновременных запросов, Windows достигнет «лимита сетевых команд BIOS на сервер», и все запросы сверх этого лимита должны будут ждать, пока IIS » закрывает сеанс "к серверу. Мне сказали, что ограничение составляет 100 файлов и его нельзя настроить.
Все это звучит немного странно. Если я настрою новый сервер Windows 2003 с настройками по умолчанию и использую его для размещения приложения ASP Classic с 15000 файлов .asp, используя общий ресурс на сервере в качестве домашнего каталога для сайта IIS, я действительно столкнусь с этими проблемами? И если да, то есть ли способ противостоять им, не меняя архитектуру?
(Чтобы уточнить, единственная причина, по которой «балансировка нагрузки» важна, заключается в том, что балансировка нагрузки является причиной того, что файлы находятся в общей папке на сервере. Если балансировка нагрузки не требуется, файлы могут находиться на локальном диске.)
Ответы 3
Для ответа 3 вы можете изменить ограничение команды Network BIOS. Это довольно простое исправление редактирования реестра: http://support.microsoft.com/kb/810886/en-us
Я сам столкнулся с этой проблемой.
Я не уверен в вашем прямом вопросе о взаимодействии между IIS и UNC, но я бы посоветовал на загруженном сайте (все, что достаточно занято, чтобы требовать балансировки нагрузки), вы рассматривали что-то другое, кроме общего доступа к файлам.
Asp, загруженный IIS по сети (то есть файловый ресурс), будет иметь негативные последствия для производительности (задержка).
Я бы предложил использовать что-то вроде robocopy, чтобы все серверы с балансировкой нагрузки синхронизировались с центральным мастером. Другими словами, разверните на одном главном сервере (или одном главном расположении), а затем скопируйте файлы на каждое подчиненное устройство в пуле балансировщика нагрузки.
Это не только устранит описанные вами странные проблемы UNC, но также даст вам хороший прирост производительности (за счет устранения попадания в сеть при загрузке asp-страниц). Если бы вы сделали это, я ожидал бы довольно значительного повышения производительности.
Да, это возможно, но да, это может вызвать проблемы.
Когда ASP.NET компилирует ASPX, ASCX и другие страницы содержимого в сборки, он создает множество FileSystemWatcher, чтобы отслеживать зависимости между ними, чтобы при изменении файлов он мог перекомпилировать. Они съедают ресурсы NetBIOS.
Кроме того, каждый раз, когда вы выполняете вызов File.Exists или Directory.Exists или любой другой тип ввода-вывода на путь обслуживания сайта, это также увеличивает требования к ограничениям NetBIOS.
Можно установить ограничения NetBIOS через реестр до определенного значения выше значений по умолчанию.
Для небольшого сайта с относительно небольшим количеством каталогов и файлов вы можете очень успешно запустить общий ресурс UNC, потому что ASP.NET продолжит работу после запуска вне своих скомпилированных сборок. Однако чем больше каталогов и файлов вы добавите, тем выше вероятность возникновения проблем.
Мы пробовали запустить гигантский сайт (сотни каталогов и файлов ASPX / ASCX), и он работал нормально в течение нескольких минут, пока не было получено достаточно URL-адресов, чтобы были достигнуты ограничения NetBIOS, а затем каждый последующий просмотр страницы приводил к исключению. В итоге мы были вынуждены использовать решение для публикации robocopy.
В конце концов, вы должны проверить, достаточно ли маленький ваш сайт и достаточно ли высокие настройки NetBIOS для эффективной работы. Я бы посоветовал использовать паука на тестовом сайте, чтобы вы могли быть уверены, что все, что может быть скомпилировано или доступно, было хотя бы один раз.
В конце концов, все идет гладко, после настройки ограничений NetBIOS и т. д. Задержка при запуске для FileSystemWatchers и компиляции ASP оказалась терпимой.
Да я согласен. На самом деле, я бы предпочел DFS, а не RoboCopy - больше настроек, но меньше бессонных ночей. Однако, как обычно, эту конкретную настройку диктуют внешние факторы.