Quelles sont les implications en termes de performances du mappage générique de toutes les demandes via IIS 6.0?

Question

Je suis intéressé à utiliser UrlRewriter.NET et remarqué dans le config page pour IIS 6.0 sur Win2k3, qu'ils disent pour mapper toutes les demandes via l'ISAPI ASP.NET. C'est bon, mais je me demande si quelqu'un a de bonnes ou de mauvaises choses à dire à propos de cette performance sage? Est-ce que mon serveur web va être mis à genoux en faisant cela ou sera-t-il plus d'un petit pas en charge de serveur? Mon serveur a actuellement de l'espace pour respirer maintenant, donc une certaine baisse de performance est attendue et acceptable.

Answer 1

Le mappage de caractères génériques a un impact énorme sur les performances, principalement parce qu'il utilise le pool de threads de l'application non pas pour le traitement des demandes de page, mais pour tout le contenu. Supposons que vous ayez une page habituelle avec au moins 10 ressources supplémentaires comme images, css et javascript - alors vous bloquez toute autre demande potentielle en servant le contenu statique directement à partir du pool. Plus d'informations sur le filetage d'asp.net IIS 6 peut être trouvé here. Une façon d'aller au-dessus (comment je l'ai fait) est de ne pas mapper les caractères génériques aux dossiers qui contiennent le contenu statique - après cela, vous recevrez uniquement une demande d'application valide comme vous le feriez dans une situation ordinaire.

La façon de démapper les répertoires statiques est de créer une application de chacun d'entre eux, puis de procéder au démontage, puis d'annuler la création de l'application. Vous pouvez trouver plus de détails sur Steve Sanderson's blog.

Answer 2

D'après ceci: http://mvolo.com/blogs/serverside/archive/2006/11/10/Stopping-hot_2D00_linking-with-IIS-and-ASP.NET.aspx ... nous parlons d'un impact de 30% des ressources utilisées pour servir les images.

Mise à jour 1: Cela dépend de la quantité de contenu dynamique ou statique que vous avez. Si vous avez suffisamment de capacité disponible, vous pouvez simplement l'allumer et suivre de près l'impact sur les performances. S'il commence à se dégrader trop, vous pouvez simplement l'éteindre. Après cela, vous pouvez procéder en toute confiance pour effectuer les modifications sans extension.

Answer 3

Peut-être un coup d'oeil à IIS 6.0 wildcard mapping benchmarks?

Il semblerait montrer ce que je l'ai vécu dans la nature depuis de nombreuses années - les frais généraux lors de l'utilisation de la dll réSEAU est négligeable. Si vous avez assez de trafic pour que ce soit un problème, il y aura une centaine de choses qui causent un plus gros goulot d'étranglement avant que ce soit le ASPNet dll