Afin de rendre l'adresse URL plus conviviale (bien sûr, il peut y avoir d'autres raisons), de nombreux sites utilisent la réécriture d'URL, comme http://www.cnblogs.com/life . Une telle réécriture d'URL est généralement gérée dans asp.net. *.* doit être mappé sur aspnet_isapi.dll (C:WINDOWSMicrosoft.NETFrameworkv1.1.432aspnet_isapi.dll) dans IIS, puis effectuez la configuration correspondante dans web.config et enfin écrivez le programme de traitement correspondant , dans la plupart des cas, nous procédons de cette façon, et Boke Park le fait de la même manière, et il ne semble pas y avoir de problème.
Cependant, il y a depuis longtemps des problèmes de performances à Boke Park. Dudu et de nombreux amis dans le jardin ont également réfléchi à de nombreuses façons d'améliorer les performances et ont obtenu d'excellents résultats, mais ce n'est toujours pas idéal, car je veux également contribuer. J'aime beaucoup BoKe Park. J'ai beaucoup appris dans le jardin. J'ai essentiellement lu les articles ci-dessus matin, midi et soir lorsqu'un ami du groupe technique m'a posé une question sur l'URL. réécriture que j'ai soudainement réalisé que BoKe Park Le problème de performances est probablement dû à la réécriture d'URL.
La question de mon ami est la suivante :
http://www.wodecity.com/food et http://www.wodecity.com/food.html (ce lien est désormais invalide) localisent tous deux la même page http://www.wodecity via la réécriture d'URL .com. /page/food.aspx , les deux utilisent le même programme de traitement. La seule différence est que pour traiter des adresses sans extensions telles que http://www.wodecity.com/food , il doit mapper *.* à aspnet_isapi. , et http://www.wodecity.com/food.html mappe *.html à aspnet_isapi.dll Il a été constaté que les performances de http://www.wodecity.com/food.html sont meilleures que celles de http:/. / www.wodecity.com/food est dix à vingt fois meilleur. Il l'a testé avec Loadrunner. Il était très déprimé par le résultat. J'ai également été surpris au début. Quelle est la différence entre *.* et *.html ? *.* signifie que toutes les requêtes pour la page, y compris les fichiers CSS et tous les fichiers image, sont traitées par le gestionnaire de réécriture d'URL écrit par lui. , *.html n'existe pas, c'est juste une demande. Le problème se pose ici. La page http://www.wodecity.com/food doit contenir plus de 20 images. Lors d'une demande de page, vous devez utiliser l'url. gestionnaire de réécriture en même temps. Ne peut-il pas être lent lors du traitement d'autant d'images ? Ce qu'il faut faire? Parce qu'ils veulent utiliser des URL comme http://www.wodecity.com/food , qui sont plus conviviales, ils doivent quand même utiliser *.* Après y avoir réfléchi un moment, je lui ai dit de laisser votre programme de réécriture d'URL. ne pas traiter ces fichiers image. C'est tout, comment faire ? Il existe deux méthodes : Méthode 1, convertir le dossier où les images sont stockées en un répertoire virtuel, puis déplacer le mappage du répertoire virtuel *.*, afin que son programme de réécriture d'URL ne traite pas les fichiers image. le stockage d'autres fichiers qui ne nécessitent pas de programme de réécriture d'URL doit être traité de la même manière que le dossier image. La méthode 2 consiste à créer un nouveau site, par exemple en utilisant http://img.wodecity.com/ pour stocker les fichiers image. la même chose. Oui, tout cela signifie que votre gestionnaire de réécriture d'URL ne traite pas ces fichiers image.
Tout allait bien. Il m'a dit qu'il irait à l'entreprise pour le tester ce matin.
Afin de vérifier mon idée, j'ai également écrit un programme pour la tester aujourd'hui. Les performances sont également près de 20 fois différentes. Bien, mon idée est correcte.
Peut-être que mes idées ou mes résultats de tests sont faux, PK est le bienvenu ici. msn:cxbsky#hotmail.com.
J'espère également que cet article sera utile pour résoudre les problèmes de performances de Blog Park, car les problèmes de Blog Park peuvent être très similaires à ceux du site de mon ami.
ps : Quand j'ai fini d'écrire cet article, j'ai interrogé mon ami sur les résultats des tests, et il m'a répondu : « À l'origine, il ne peut prendre en charge que 50 personnes. Maintenant, ce n'est plus un problème pour plus de 700 personnes.
http://www.cnblogs.com/csky/archive/2006/08/09/urlrewrite.html