Сайт IIS на доле UNC: действительно ли это проблематично?
Теперь это:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
Database.SetInitializer<YourDbContext>(null);
base.OnModelCreating(modelBuilder);
}
в вашем файле YourDbContext.cs.
3 ответа
Да, это возможно, но да, это может вызвать проблемы.
Когда ASP.NET компилирует ASPX, ASCX и другие страницы содержания в блоки, он создает много FileSystemWatchers для контроля зависимостей между ними так, чтобы, когда файлы изменяются, он мог перекомпилировать. Они съедают ресурсы NetBIOS.
Кроме того, каждый раз Вы делаете Файл. Существует или Каталог. Существует вызов или любой другой вид IO к пути обслуживания сайта, который увеличивает требования к пределам NetBIOS также.
Возможно установить пределы NetBIOS через реестр к выше их значений по умолчанию к точке.
Для небольшого сайта, с относительно немногими каталогами и файлами, Вы могли очень успешно убежать доля UNC, потому что ASP.NET продолжит бежать за запуском прочь его скомпилированных блоков. Однако, чем больше каталогов и файлов Вы добавляете, тем более вероятные проблемы состоят в том, чтобы неожиданно возникнуть.
Мы пытались выполнить гигантский сайт (сотни каталогов и файлов ASPX/ASCX), и он будет хорошо работать в течение нескольких минут, пока к достаточному количеству URL не получили доступ, что пределы NetBIOS были достигнуты, и затем каждый последующий просмотр страницы привел к исключению. Мы закончили вынужденные использовать robocopy публикация решения.
В конце необходимо протестировать, чтобы видеть, является ли сайт достаточно небольшим, и настройки NetBIOS достаточно высоки для выполнения эффективно. Я предложил бы использовать паука на испытательной площадке так, чтобы можно было быть уверены, что все, что могло быть скомпилировано или получено доступ, по крайней мере, однажды.
Я не уверен в Вашем прямом вопросе на взаимодействии между IIS и UNC, но я предложил бы на оживленном сайте (что-либо достаточно занятое для требования выравнивания нагрузки), что Вы рассматриваете что-то другое, чем доля файла.
Asp, загруженный IIS через сеть (т.е. доля файла), перенесет отрицательные последствия производительности (задержка).
Я предложил бы использовать что-то как robocopy для хранения сбалансированных серверов всей загрузки в синхронизации с центральным ведущим устройством. Другими словами, развернитесь к единственному главному серверу (или единственному основному местоположению), затем robocopy файлы к каждому ведомому устройству в пуле подсистемы балансировки нагрузки.
Это не только удалит странные проблемы UNC, которые Вы описываете, но должны также дать Вам хорошее повышение производительности (путем удаления сетевого хита при загрузке страниц ASP). Я ожидал бы довольно тяжелые повышения производительности, если бы Вы сделали это.
Для ответа 3 можно изменить предел команды Network BIOS. Это - довольно легкое редактирование реестра, зафиксируйте: http://support.microsoft.com/kb/810886/en-us
Я столкнулся с тем конкретным вопросом сам.