Points de repère pour le mappage générique IIS 6.0?

Question

Je suis rapidement tombé en amour avec ASP.NET MVC bêta, et l'une des choses que j'ai décidé que je n'aurez pas à sacrifier dans le déploiement de mon IIS 6 environnement d'hébergement est la extensionless URL. Je suis donc à la pesée de l'examen de l'ajout d'un générique de cartographie, mais tout ce que je lis, indique un potentiel de gain de performance lors de l'utilisation de cette méthode. Cependant, je ne trouve pas de réels repères!

La première partie de cette question est, savez-vous où je pourrais trouver ces références, ou est-ce juste une hypothèse non vérifiée?

La deuxième partie de la question est en ce qui concerne les 2 tests de charge, j'ai couru à l'aide de jMeter sur notre serveur de dev sur un 100Mbs connexion.

Informations De Fond

Notre hébergeur a 4Gbs modulable internet pipe avec une 1Gbs épine dorsale de notre VLAN, donc tout ce que je peux produire sur le bureau local doit s'intégrer à l'environnement d'hébergement.

Le scénario de test a été de charger plusieurs images / css fichiers, depuis la soi-disant performances vient lors de la demande de fichiers qui sont maintenant passés par la ASP.NET filtre ISAPI qui ne seraient normalement pas passer au travers. Chaque test contenait 50 threads (simulé utilisateurs) l'exécution de la demande de script pour 1000 itérations chaque. Les résultats de chaque test sont affichés ci-dessous.

Des Résultats De Test

Sans mappage de caractères génériques:

Des échantillons: de 50 000
Temps de réponse moyen: 428ms
Nombre d'erreurs: 0
Requêtes par seconde: 110.1
Kilo-octets par seconde: 11,543

Avec le générique de la cartographie:

Des échantillons: de 50 000
Temps de réponse moyen: 429ms
Nombre d'erreurs: 0
Requêtes par seconde: 109.9
Kilo-octets par seconde: 11,534

Les deux tests ont été exécutés chaud (tout était dans la mémoire, pas de chargement initial de polarisation), et de mon point de vue, la performance était sur le même. Utilisation de l'UC, a été d'environ 60% pendant toute la durée des tests, la mémoire était très bien, et l'utilisation du réseau est resté stable autour de 90-95%.

Est-ce une preuve suffisante que l'génériques mappages de passer à travers la ASP.NET filtre pour TOUS les contenus ne sont pas vraiment affecter les performances, ou ai-je raté quelque chose?

Edit: de 11 heures et pas un seul commentaire? J'espérais plus.. lol

Answer 1

Chris, très pratique post.

Beaucoup de ceux qui suggèrent un impact négatif sur les performances en déduire que le code obtenu dans une application web est d'une façon différente/inférieure à code traitées dans le flux de travail standard. Le code de base de type peut-être différents, et bien sûr vous allez avoir besoin d'MSIL interprète, mais MS a montré dans de nombreux cas, vous verrez une augmentation de la performance dans une .NET runtime sur un natif.

Il est également sage de considérer la façon dont IIS doit être un "jack de tous les métiers" - permettant toutes sortes de configuration et remplace même sur des fichiers statiques. Certains de ceux qui sont conçus pour augmenter la performance (mise en cache, la compression) et, en effet, seront perdues sauf si vous réimplémenter dans votre code, mais beaucoup d'entre eux sont pour d'autres fins et ne peut jamais être utilisé. Si vous créez pour vos besoins (uniquement), vous pouvez ignorer ces autres morceaux et devrait être la réalisation de certains type de performance, même si il y a un potentiel ASP.NET désavantage.

Dans mon (non-.NET) MVC test je vais voir considérable (10x ou plus) des avantages de performance de plus de webforms. Même si il y avait un petit coup sur le contenu statique - qui ne serait pas une pilule difficile à avaler.

Je ne suis pas surpris que la différence est presque négligeable dans vos tests, mais je suis heureux de voir qu'il sauvegardés.

REMARQUE: Vous pouvez désactiver le mappage de caractères génériques de la statique des répertoires (je garde tous les fichiers statiques dans /static/(photos|styles|...)) dans IIS. Basculez le dossier vers une application, supprimer le mappage de caractères génériques, et de le basculer en arrière à partir d'une application et d' - voilà - les fichiers statiques sont gérées par IIS sans importuner votre ASP.NET.

Answer 2

Je pense qu'il y a plusieurs choses à vérifier:

• Puisque nous utilisons le filtre .Net ISAPI, nous utilisons peut-être des threads utilisés pour exécuter des applications afin de servir des actifs statiques. J'exécuterais le même test de charge lors de l'examen des compteurs de performance des threads - Cliquez sur ce lien
• J'exécuterais le même test de charge en même temps que Microsoft Performance Analyzer et comparerais les rapports.

Answer 3

Je cherchais depuis longtemps un repère comme celui-ci. Merci!

Dans mon entreprise, nous avons créé des correspondances génériques sur plusieurs sites Web (formulaires Web standard, .net1.1 et 2, iis6), et les administrateurs système m'ont dit qu'ils n'avaient constaté aucun problème de performances.

Mais, il semble que vous ayez insisté sur le réseau, pas sur le serveur. Alors peut-être que les scores sont si similaires à cause du goulot d'étranglement du réseau? Juste à y penser...

Answer 4

Il semble que le goulot d’étranglement de votre test soit l’utilisation du réseau. Si la dégradation des performances est supposée être liée à l'utilisation du processeur (je ne suis pas sûr que ce soit le cas, mais que c'est raisonnable), vous ne le remarqueriez pas avec le test que vous avez effectué.

Comme il s’agit d’un système complexe comportant de nombreuses variables, cela ne signifie pas qu’il n’ya aucune dégradation des performances. Cela signifie que dans votre scénario, la dégradation des performances est probablement négligeable.