Сайт IIS на ресурсе UNC:это проблематично?

Question

Я работаю с устаревшим решением ASP Classic, которое сбалансировано по нагрузке (через внешнее оборудование и имеет сайт IIS, домашний каталог которого является путем UNC.Мне сказали, что в настоящее время существуют следующие проблемы с этой настройкой:

1. При использовании пути UNC в качестве домашнего каталога где-то в IIS существует «индекс», который «кэширует» до определенного количества файлов определенных типов, и при достижении предела, который по умолчанию равен 50, последующие запросы к страницы, которых нет в кеше, вернут 404.
2. При использовании пути UNC в качестве домашнего каталога при запуске сайта IIS вышеупомянутый «кэш» начнет заполняться, что приводит к зависанию IIS сайта до тех пор, пока кеш не заполнится, а это означает, что огромные сайты (15 000 файлов .asp) недоступны для до 30 минут после запуска сайта IIS.
3. При использовании пути UNC в качестве домашнего каталога, если к сайту выполняется более определенного количества одновременных запросов, Windows достигнет «ограничения количества команд BIOS сети на сервер», и все запросы, превышающие этот предел, должны будут ждать, пока IIS « закрывает сеанс" на сервере.Мне сказали, что ограничение составляет 100 файлов и не настраивается.

Сейчас все это звучит немного странно.Если я настрою новый сервер Windows 2003 с настройками по умолчанию и использую его для размещения классического приложения ASP с 15 000 файлов .asp, используя общий ресурс на сервере в качестве домашнего каталога для сайта IIS, столкнусь ли я на самом деле с этими проблемами?И если да, то есть ли способ им противостоять, не меняя архитектуру?

(Для пояснения: единственная причина, по которой важна «балансировка нагрузки», заключается в том, что балансировка нагрузки является причиной того, что файлы находятся в общем ресурсе на сервере.Если бы балансировка нагрузки не требовалась, файлы могли бы находиться на локальном диске.)

Answer 1

Да, это возможно, но да, это может вызвать проблемы.

Когда ASP.NET компилирует ASPX, ASCX и другие страницы контента в сборки, он создает множество FileSystemWatcher для отслеживания зависимостей между ними, чтобы при изменении файлов можно было перекомпилировать их.Они съедают ресурсы NetBIOS.

Кроме того, каждый раз, когда вы выполняете вызов File.Exists или Directory.Exists или любой другой вид ввода-вывода на пути обслуживания сайта, это также увеличивает требования к ограничениям NetBIOS.

Через реестр можно установить ограничения NetBIOS в несколько раз выше значений по умолчанию.

Для небольшого сайта с относительно небольшим количеством каталогов и файлов вы можете очень успешно использовать общий ресурс UNC, поскольку ASP.NET продолжит работу после запуска скомпилированных сборок.Однако чем больше каталогов и файлов вы добавите, тем больше вероятность возникновения проблем.

Мы попытались запустить огромный сайт (сотни каталогов и файлов ASPX/ASCX), и он работал нормально в течение нескольких минут, пока не было получено достаточное количество URL-адресов, чтобы были достигнуты ограничения NetBIOS, а затем каждый последующий просмотр страницы приводил к исключению.В итоге мы были вынуждены использовать решение для публикации робокопий.

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

Answer 2

Я не уверен в вашем прямом вопросе о взаимодействии между IIS и UNC, но я бы посоветовал на загруженном сайте (все, что достаточно занято, чтобы требовать балансировки нагрузки), рассмотреть что-то иное, чем общий файловый ресурс.

Asp, загружаемый IIS по сети (т. е.общий файловый ресурс) пострадает от негативных последствий для производительности (задержка).

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

Это не только устранит странные проблемы UNC, которые вы описываете, но также должно дать вам хороший прирост производительности (за счет устранения попадания в сеть при загрузке страниц asp).Я бы ожидал довольно значительного повышения производительности, если бы вы это сделали.

Answer 3

Для ответа 3 вы можете изменить ограничение команд Network BIOS.Это довольно простое исправление редактирования реестра: http://support.microsoft.com/kb/810886/en-us

Я сам столкнулся с этой конкретной проблемой.