IIS local no compartilhamento UNC: é problemático?

Question

Eu estou trabalhando com uma solução legado ASP clássico que é carga balanceada (via hardware externo e tem um IIS local o diretório home, que é um caminho UNC Eu tenho dito que os seguintes problemas com esta configuração existem atualmente.:

1. Ao usar um caminho UNC como diretório home, há uma em algum lugar "index" no IIS que "caches" até uma certa quantidade de certos tipos de arquivos, e quando o limite, cujo padrão é 50, foi atingido, os pedidos subsequentes para não páginas em cache retornará 404.
2. Ao usar um caminho UNC como diretório home, quando se inicia o site do IIS, o "cache" acima mencionado será iniciado o enchimento, que vai atolar o site do IIS até que o cache é preenchido, o que significa que grandes locais (15.000 ASP arquivos) não estão disponíveis para até 30 minutos depois que o site começa IIS.
3. Ao usar um caminho UNC como diretório home, se mais do que um certo número de solicitações simultâneas são feitas para o site, o Windows vai chegar ao "limite de comandos BIOS da rede por servidor", e todos os pedidos acima do limite terá que esperar até que o IIS "fecha a sessão" para o servidor. Foi-me dito o limite é de 100 arquivos e não configurável.

Agora, tudo isso soa um pouco estranho. Se eu criar um novo servidor Windows 2003 com configurações padrão, e usá-lo para hospedar um aplicativo ASP clássico com 15.000 arquivos.asp, usando um compartilhamento em um servidor como o diretório home para o site do IIS, irá Eu realmente executado para esses problemas? E se assim for, há uma maneira de combatê-los sem alterar a arquitetura?

(Para esclarecer, a única razão que o "balanceamento de carga" é importante é que o balanceamento de carga é a razão pela qual os arquivos estão em um compartilhamento em um servidor. Se não balanceamento de carga foi necessário, os arquivos podem estar no disco local. )

Answer 1

Sim, é possível, mas sim, ele pode causar problemas.

Quando ASP.NET compila ASPX, ASCX, e outras páginas de conteúdo em conjuntos, ele cria um monte de FileSystemWatchers a fim de monitorar as dependências entre eles, para que quando os arquivos alterar, pode recompilar. Estes comer até recursos de NetBIOS.

Além disso, cada vez que você faz um File.Exists ou Directory.Exists chamar, ou qualquer outro tipo de IO a caminho servindo do site, que aumenta as exigências sobre os limites de NetBIOS também.

É possível definir os limites de NetBIOS através do Registro para acima de seus padrões para um ponto.

Para um pequeno local, com relativamente poucos diretórios e arquivos, você poderia muito executar com êxito fora de um compartilhamento UNC porque ASP.NET continuará a funcionar após a inicialização fora de suas montagens compilados. No entanto, os mais diretórios e arquivos que você adiciona, os problemas estão mais propensos a surgir.

Nós tentamos executando um site de mamute (centenas de diretórios e arquivos ASPX / ASCX) e ele iria correr bem por alguns minutos até urls suficientes foram acessados ??que os limites de NetBIOS foram alcançados, e depois a cada visualização de página subsequente resultou em uma exceção . Acabamos forçados a usar uma solução de publicar robocopy.

No final, você tem que testar para ver se o site é pequeno o suficiente e suas configurações de NetBIOS são altos o suficiente para executar de forma eficaz. Gostaria de sugerir o uso de uma aranha em um site de teste de modo que você pode ter certeza que tudo o que poderia ser compilado ou acessado é pelo menos uma vez.

Answer 2

Eu não tenho certeza sobre a sua pergunta direta sobre a interação entre o IIS e UNC, mas gostaria de sugerir em um site ocupado (nada ocupado o suficiente para exigir o balanceamento de carga), que você considere algo diferente de um compartilhamento de arquivo.

Um asp carregado pelo IIS através de uma rede (ou seja, um compartilhamento de arquivos) vai sofrer implicações de desempenho negativas (latência).

sugiro usar algo como robocopy para manter todos os servidores com balanceamento de carga em sincronia com um mestre central. Em outras palavras, deploy para um único servidor mestre (ou localização mestre único), então robocopy os arquivos para cada escravo na piscina do balanceador de carga.

Isto não só irá remover as questões estranhas UNC que você descreve, mas deve também dar-lhe um aumento de performance agradável (removendo a rede sucesso quando carregar páginas ASP). Eu esperaria aumentos de performance muito pesadas se você fez isso.

Answer 3

Como resposta 3 pode alterar o limite de comandos BIOS da rede. É um muito fácil de registro editar correção: http://support.microsoft.com/kb/ 810886 / en-us

Eu tenho que correr para esse problema específico mim mesmo.