Сайт IIS на UNC share: это проблематично? - PullRequest
7 голосов
/ 24 сентября 2008

Я работаю с устаревшим решением 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 Classic с 15 000 .asp-файлов, используя общий ресурс на сервере в качестве домашнего каталога для сайта IIS, я действительно запусту в эти проблемы? И если да, то есть ли способ противостоять им, не меняя архитектуру?

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

Ответы [ 3 ]

5 голосов
/ 10 декабря 2008

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

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

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

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

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

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

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

2 голосов
/ 24 сентября 2008

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

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

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

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

1 голос
/ 24 сентября 2008

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

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

...