Site IIS sur le partage UNC: est-ce problématique?

Question

Je travaille avec une solution classique ASP Classic équilibrée en charge (via du matériel externe et un site IIS dont le répertoire de base est un chemin UNC. On m'a informé que les problèmes suivants liés à cette configuration existent actuellement:

1. Lors de l'utilisation d'un chemin UNC comme répertoire de base, un "index" est créé. quelque part dans IIS qui "caches" jusqu'à un certain nombre de fichiers de certains types, et lorsque la limite (50 par défaut) est atteinte, les requêtes suivantes adressées aux pages ne se trouvant pas dans le cache renverront 404.
2. Lors de l'utilisation d'un chemin UNC comme répertoire de base, lors du démarrage du site IIS, le "cache" susmentionné commence à se remplir, ce qui enlèvera le site IIS jusqu'à ce que le cache soit rempli, ce qui signifie que les sites volumineux (15 000 fichiers .asp) ne sont pas disponibles jusqu'à 30 minutes après le démarrage du site IIS.
3. Lors de l'utilisation d'un chemin UNC comme répertoire de base, si plus d'un certain nombre de demandes simultanées sont adressées au site, Windows atteindra la "limite de commande du BIOS du réseau par serveur", et toutes les demandes dépassant cette limite devront attendez que IIS "ferme la session". au serveur. On me dit que la limite est de 100 fichiers et non configurable.

Maintenant, tout cela semble un peu bizarre. Si je configure un nouveau serveur Windows 2003 avec des paramètres par défaut et que je l’utilise pour héberger une application ASP Classic contenant 15 000 fichiers .asp, en utilisant un partage sur un serveur comme répertoire de base du site IIS, puis-je exécuter le logiciel dans ces problèmes? Et si oui, y a-t-il moyen de les contrer sans changer l’architecture?

(Pour clarifier, la seule raison pour laquelle l '"équilibrage de la charge" est important est que l'équilibrage de la charge est la raison pour laquelle les fichiers se trouvent sur un partage sur un serveur. Si aucun équilibrage de la charge n'était nécessaire, ils pourraient se trouver sur le disque local. .)

Answer 1

Oui, c'est possible, mais oui, cela peut causer des problèmes.

Lorsque ASP.NET compile des pages ASPX, ASCX et autres pages de contenu en assemblys, il crée un grand nombre de FileSystemWatchers afin de surveiller les dépendances entre eux afin que, lorsque les fichiers changent, ils puissent être recompilés. Ces ressources dévorent les ressources NetBIOS.

De plus, chaque fois que vous appelez File.Exists ou Directory.Exists, ou tout autre type d'E / S vers le chemin de desserte du site, cela augmente également la charge imposée aux limites NetBIOS.

Il est possible de définir les limites NetBIOS par le biais du registre au-dessus de leurs valeurs par défaut.

Pour un petit site, avec relativement peu de répertoires et de fichiers, vous pouvez très bien exécuter un partage UNC car ASP.NET continuera à s'exécuter après le démarrage de ses assemblys compilés. Cependant, plus vous ajoutez de répertoires et de fichiers, plus les problèmes risquent de surgir.

Nous avons essayé de gérer un site gigantesque (des centaines de répertoires et de fichiers ASPX / ASCX) et tout se passait bien pendant quelques minutes jusqu'à ce qu'un nombre suffisant d'URL soient atteintes pour que les limites NetBIOS soient atteintes. Chaque affichage de page suivant entraînait une exception. . Nous avons fini par être obligés d'utiliser une solution de publication robocopy.

En fin de compte, vous devez vérifier si votre site est suffisamment petit et si vos paramètres NetBIOS sont suffisamment élevés pour fonctionner correctement. Je suggérerais d'utiliser une araignée sur un site de test pour être sûr que tout ce qui peut être compilé ou auquel on a accès est au moins une fois.

Answer 2

Je ne suis pas sûr de votre question directe sur l'interaction entre IIS et UNC, mais je suggérerais que sur un site occupé (toute activité suffisante pour exiger un équilibrage de charge), vous envisagiez autre chose qu'un partage de fichiers.

Un asp chargé par IIS sur un réseau (par exemple, un partage de fichiers) aura des conséquences négatives sur les performances (latence).

Je suggérerais d'utiliser quelque chose comme robocopy pour maintenir tous les serveurs à charge équilibrée synchronisés avec un maître central. En d’autres termes, déployez-vous sur un seul serveur maître (ou sur un seul emplacement maître), puis effectuez une photocopie des fichiers sur chaque esclave du pool de l’équilibreur de charge.

Cela supprimera non seulement les problèmes UNC délirants que vous décrivez, mais devrait également vous donner un avantage considérable en termes de performances (en supprimant l'impact du réseau lors du chargement de pages asp). Je m'attendrais à des gains de performances assez importants si vous agissiez ainsi.

Answer 3

Pour la réponse 3, vous pouvez modifier la limite de commande du BIOS du réseau. C'est un correctif de modification du registre assez facile: http://support.microsoft.com/kb/ 810886 / fr-us

J'ai moi-même rencontré ce problème particulier.