Para que la dirección URL sea más amigable (por supuesto, puede haber otras razones), muchos sitios utilizan la reescritura de URL, como http://www.cnblogs.com/life . Dicha reescritura de URL generalmente se maneja en asp.net. *.* debe asignarse a aspnet_isapi.dll (C:WINDOWSMicrosoft.NETFrameworkv1.1.432aspnet_isapi.dll) en IIS, luego realizar la configuración correspondiente en web.config y finalmente escribir el programa de procesamiento correspondiente. , en la mayoría de los casos lo hacemos así, y Boke Park lo hace igual, y no parece haber ningún problema.
Sin embargo, Dudu ha tenido problemas de rendimiento durante mucho tiempo y muchos amigos en el jardín también han pensado en muchas formas de mejorar el rendimiento y han logrado excelentes resultados, pero todavía no es lo ideal, porque yo también quiero contribuir. Me gusta mucho BoKe Park. Aprendí mucho en el jardín. Básicamente leí los artículos anteriores por la mañana, al mediodía y por la noche. No fue hasta anoche cuando un amigo del grupo técnico me hizo una pregunta. reescribiendo que de repente me di cuenta de que BoKe Park El problema de rendimiento probablemente se debe a la reescritura de la URL.
La pregunta de mi amigo es esta:
http://www.wodecity.com/food y http://www.wodecity.com/food.html (este enlace ahora no es válido) ubican la misma página http://www.wodecity mediante la reescritura de URL .com. /page/food.aspx , ambos usan el mismo programa de procesamiento. La única diferencia es que para procesar direcciones sin extensiones como http://www.wodecity.com/food , debe asignar *.* a aspnet_isapi. y http://www.wodecity.com/food.html asigna *.html a aspnet_isapi.dll. Se descubrió que el rendimiento de http://www.wodecity.com/food.html es mejor que http:/. / www.wodecity.com/food es de diez a veinte veces mejor. Lo probó con loadrunner. Estaba muy deprimido por el resultado. También me sorprendió al principio ¿Cuál es la diferencia entre *.* y *.html? *.* significa que todas las solicitudes de la página, incluidos los archivos css y todos los archivos de imagen, son procesadas por el controlador de reescritura de URL escrito por él. , *.html no existe, es solo una solicitud. El problema surge aquí. La página http://www.wodecity.com/food debe tener más de 20 imágenes. Al solicitar una página, debe utilizar la URL. Reescribir el controlador al mismo tiempo. ¿No puede ser lento al procesar tantas imágenes? ¿Qué hacer? Como quieren usar URL como http://www.wodecity.com/food , que es más amigable, todavía tienen que usar *.*. Después de pensarlo por un tiempo, le dije que dejara su programa de reescritura de URL. No procesar esos archivos de imagen. Eso es todo, ¿cómo hacerlo? Hay dos métodos: Método 1, convertir la carpeta donde están almacenadas las imágenes en un directorio virtual y luego mover la asignación del directorio virtual *.*, para que su programa de reescritura de URL no procese los archivos de imágenes. almacenar otros archivos que no requieren un programa de reescritura de URL debe tratarse de manera similar a la carpeta de imágenes. El método 2 es crear un nuevo sitio, como usar http://img.wodecity.com/ para almacenar archivos de imágenes. Lo mismo. Sí, todo significa que su controlador de reescritura de URL no procesa esos archivos de imagen.
Todo estaba bien. Me dijo que iría a la empresa a probarlo esta mañana.
Para verificar mi idea, también escribí un programa para probarla hoy. El rendimiento también es casi 20 veces diferente. Bueno, mi idea es correcta.
Tal vez mis ideas o los resultados de mis pruebas sean incorrectos, PK es bienvenido aquí. msn:cxbsky#hotmail.com.
También espero que este artículo sea útil para los problemas de rendimiento de Blog Park, porque los problemas en Blog Park pueden ser muy similares a los del sitio de mi amigo.
PD: Cuando terminé de escribir este artículo, le pregunté a mi amigo sobre los resultados de la prueba y me dijo: "Originalmente, solo podía soportar a 50 personas. Ahora no es un problema para más de 700 personas".
http://www.cnblogs.com/csky/archive/2006/08/09/urlrewrite.html