Los desarrolladores de ASP se esfuerzan continuamente por lograr un mejor rendimiento y escalabilidad en sus proyectos de diseño. Afortunadamente, existen muchos libros y sitios que ofrecen excelentes consejos en esta área. Sin embargo, estas sugerencias se basan en conclusiones extraídas de la estructura del trabajo de la plataforma ASP y no existe una medición cuantitativa de la mejora real del rendimiento. Debido a que estas recomendaciones requieren una codificación más compleja y hacen que el código sea menos legible, los desarrolladores deben sopesar si vale la pena el costo de mejorar el rendimiento de sus aplicaciones ASP sin ver resultados reales.
Este artículo se divide en dos partes. Presentaré algunos resultados de pruebas de rendimiento para ayudar a los desarrolladores a determinar si una iniciativa en particular vale la pena no solo para proyectos futuros, sino también para actualizar el proyecto original. En la primera parte revisaré algunas cuestiones básicas del desarrollo de ASP. En la segunda parte, cubrirá la optimización de algunas funciones ADO y comparará sus resultados con páginas ASP que llaman objetos VB COM para realizar las mismas funciones ADO. Los resultados son reveladores y a veces sorprendentes.
En este artículo, responderemos las siguientes preguntas:
* ¿Cuál es la forma más eficaz de escribir contenido generado por ASP en el flujo de respuesta?
* ¿Debería habilitarse el búfer?
* ¿Debería considerar agregar comentarios a su código ASP?
* ¿Debería establecerse explícitamente el idioma predeterminado para la página?
* ¿Debería cerrarse el estado de la sesión si no es necesario?
* ¿Debería colocarse la lógica de script en subrutinas y áreas de funciones?
* ¿Cuáles son las implicaciones del uso de archivos de inclusión?
* ¿Qué tipo de carga se impone al realizar el manejo de errores?
* ¿La configuración de un controlador de contexto tiene algún impacto en el rendimiento?
Todas las pruebas se realizaron utilizando la herramienta Web Application Focus Tool (WAST) de Microsoft, una herramienta gratuita que se puede encontrar aquí. Creé un script de prueba simple usando WAST que llamó repetidamente a las pruebas de la página ASP que se describen a continuación (más de 70.000 veces cada una). El tiempo de respuesta se basa en el tiempo total promedio del último byte (TTLB), que es el tiempo desde el momento de la solicitud inicial hasta el momento en que la herramienta recibe el último bit de datos del servidor. Nuestro servidor de prueba es un Pentium 166 con 196 MB de RAM y el cliente es un Pentium 450 con 256 MB de RAM. Podrías pensar que el rendimiento de estas máquinas no es muy avanzado, pero no olvides que no estamos probando la capacidad del servidor, solo estamos probando el tiempo que tarda el servidor en procesar una página a la vez. Las máquinas no realizan ningún otro trabajo durante la prueba. Los scripts de prueba WAST, los informes de prueba y todas las páginas de prueba ASP se incluyen en el archivo ZIP para que usted pueda revisarlos y probarlos usted mismo.
¿Cuál es la forma más eficaz de escribir contenido generado por ASP en el flujo de respuesta?
Una de las principales razones para utilizar ASP es generar contenido dinámico en el servidor. Entonces, el punto de partida obvio para nuestras pruebas es determinar la forma más adecuada de enviar contenido dinámico al flujo de respuesta. Entre las muchas opciones, dos son las más básicas: una es usar etiquetas ASP en línea y la otra es usar la declaración Response.Write.
Para probar estas opciones, creamos una página ASP simple en la que definimos algunas variables y luego insertamos sus valores en una tabla. Aunque esta página es simple y poco práctica, nos permite aislar y probar algunos problemas individuales.
Usando etiquetas ASP en línea
La primera prueba implica el uso de la etiqueta ASP en línea < %= x % >, donde x es una variable asignada. Este método es, con diferencia, el más fácil de realizar y mantiene la parte HTML de la página en un formato fácil de leer y mantener.
＜% OPCIÓN EXPLÍCITA
Nombre tenue
DimApellido
Dim MiddleInicial
Dirección tenue
Ciudad oscura
Estado oscuro
Número de teléfono tenue
Número de fax oscuro
Correo electrónico oscuro
fecha de nacimiento tenue
Nombre = Juan
Inicial Medio = Q
Apellido = Público
Dirección = 100 calle principal
Ciudad=Nueva York
Estado = Nueva York
Número de teléfono = 1-212-555-1234
Número de fax = 1-212-555-1234
Correo electrónico = [email protected]
Fecha de nacimiento = 1/1/1950
%>
＜HTML＞
＜CABEZA＞
＜ TÍTULO ＞Prueba de respuesta ＜ / TÍTULO ＞
＜ /CABEZA ＞
＜CUERPO＞
＜ H1 ＞Prueba de respuesta ＜ /H1 ＞
＜ TABLA ＞
＜ tr ＞＜ td ＞＜ b ＞Nombre:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Nombre % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Inicial media:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Inicial media % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Apellido:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Apellido % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Dirección:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Dirección % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Ciudad:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Ciudad % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Estado:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Estado % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Número de teléfono:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Número de teléfono % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Número de fax:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Número de fax % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Correo electrónico:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Correo electrónico % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Fecha de nacimiento:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Fecha de nacimiento % ＞＜ /td ＞＜ /tr ＞
＜ /TABLA ＞
＜ /CUERPO ＞
＜ /HTML ＞
El código completo de /app1/response1.asp
Mejor anterior (velocidad de respuesta) = 8,28 ms/página
Utilice la declaración Response.Write en cada línea de HTML
Muchos de los mejores documentos de aprendizaje recomiendan evitar el método anterior. La razón principal de esto es que, en el proceso de generar la página y procesarla para imponer latencia, si el servidor web tiene que realizar una conversión entre enviar HTML simple y procesar secuencias de comandos, se produce un problema llamado cambio de contexto. Cuando la mayoría de los programadores escuchan esto, su primera reacción es envolver cada línea de HTML sin formato en una función Response.Write.
…
Respuesta.Escribir(<html>)
Respuesta.Escribir(＜cabeza＞)
Response.Write(＜título＞Prueba de respuesta＜/título＞)
Respuesta.Escribir(＜/head＞)
Respuesta.Escribir(<cuerpo>)
Respuesta.Escribir(＜h1＞Prueba de respuesta＜/h1＞)
Respuesta.Escribir(＜tabla＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Nombre:＜ /b ＞＜ /td ＞＜ td ＞ & Nombre & ＜ /td ＞＜ /tr ＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Inicial del segundo nombre:＜ /b ＞＜ /td ＞＜ td ＞ & MiddleInitial & ＜ /td ＞＜ /tr ＞)
… <
Fragmento de /app1/response2.asp
Mejor anterior (velocidad de respuesta) = 8,28 ms/página
Tiempo de respuesta = 8,08 ms/página
Diferencia = -0,20 ms (reducción del 2,4%)
Podemos ver que la ganancia de rendimiento al usar este enfoque es muy pequeña en comparación con el uso del marcado en línea, tal vez porque la página carga el servidor con un montón de pequeñas llamadas a funciones. La mayor desventaja de este enfoque es que dado que el HTML ahora está incrustado en el script, el código del script se vuelve más detallado y más difícil de leer y mantener.
Usar funciones contenedoras
Quizás el descubrimiento más desalentador al intentar utilizar el enfoque de declaración Response.Write es que la función Response.Write no puede colocar un CRLF al final de cada línea. Entonces, cuando lees el código fuente desde el navegador, el HTML que estaba perfectamente diseñado ahora es una línea sin fin. Creo que su próximo descubrimiento puede ser aún más aterrador: no hay una función hermana Writeln en el objeto Respuesta. Entonces, una reacción obvia es crear una función contenedora para la función Response.Write para agregar un CRLF a cada línea.
…
writeCR(＜ tr ＞＜ td ＞＜ b ＞Nombre:＜ /b ＞＜ /td ＞＜ td ＞ & Nombre & ＜ /td ＞＜ /tr ＞)
…
SUB escribirCR(cadena)
Respuesta.Escribir(cadena y vbCRLF)
FINAL SUB
Fragmento de /app1/response4.asp
Mejor anterior (velocidad de respuesta) = 8,08 ms/página
Tiempo de respuesta = 10,11 ms/página
Diferencia = +2,03 ms (aumento del 25,1%)
Por supuesto, dado que este enfoque duplica efectivamente el número de llamadas a funciones, su impacto en el rendimiento es significativo y debe evitarse a toda costa. Irónicamente, CRLF también agrega 2 bytes por línea al flujo reactivo, que el navegador no necesita representar en la página. Todo lo que hace el HTML bien formateado es facilitar que sus competidores lean su código fuente HTML y comprendan su diseño.
Concatenar respuestas consecutivas. Escribir en una sola declaración
Independientemente de nuestras pruebas anteriores con funciones contenedoras, el siguiente paso lógico es extraer todas las cadenas de las declaraciones Response.Write separadas y concatenarlas en una sola declaración, reduciendo así la cantidad de llamadas a funciones, mejorando en gran medida el rendimiento de la página.
…
Respuesta.Escribir(<html>&_
＜ cabeza ＞ & _
＜título＞Prueba de respuesta＜/título＞ & _
＜ /cabeza ＞ & _
＜cuerpo＞ & _
＜ h1 ＞Prueba de respuesta＜ /h1 ＞ & _
＜ tabla ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Nombre:＜ /b ＞＜ /td ＞＜ td ＞ & Nombre & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Fecha de nacimiento:＜ /b ＞＜ /td ＞＜ td ＞ & Fecha de nacimiento & ＜ /td ＞＜ /tr ＞ & _
＜ /tabla ＞ & _
＜ /cuerpo ＞ & _
＜/html＞)
Fragmento de /app1/response3.asp
Mejor anterior (velocidad de respuesta) = 8,08 ms/página
Tiempo de respuesta = 7,05 ms/página
Diferencia = -1,03 ms (reducción del 12,7%)
Actualmente, esta es la configuración más optimizada.
Concatenar respuestas consecutivas. Escriba en una sola declaración, agregando un CRLF al final de cada línea.
En consideración a aquellos que requieren que su código fuente se vea impecable desde un navegador, utilicé la constante vbCRLF para insertar algunos retornos de carro al final de cada línea en la prueba anterior y lo volví a ejecutar.
…
Respuesta.Escribir(<html>&vbCRLF&_
＜ cabeza ＞ & vbCRLF & _
＜ título ＞Prueba de respuesta＜ /título ＞ & vbCRLF & _
＜ /cabeza ＞ & vbCRLF & _
…
Fragmento de /app1/response5.asp
Mejor anterior (velocidad de respuesta) = 7,05 ms/página
Tiempo de respuesta = 7,63 ms/página
Diferencia = +0,58 ms (aumento del 8,5%)
El resultado es una ligera disminución en el rendimiento, quizás debido a la concatenación adicional y al mayor número de caracteres.
Revisión y observación
Se pueden extraer algunas reglas de las pruebas anteriores sobre la salida ASP:
* Evite el uso excesivo de ASP en línea.
* Siempre concatene respuestas consecutivas. Escriba declaraciones en una sola declaración.
* Nunca utilice funciones contenedoras alrededor de Response.Write para agregar CRLF.
* Si se debe formatear la salida HTML, agregue CRLF directamente dentro de la declaración Response.Write.
¿Debería habilitarse el búfer?
Iniciar búfer mediante script
Al incluir Response.Buffer=True en la parte superior del script ASP, IIS almacenará en caché el contenido de la página.
＜% OPCIÓN EXPLÍCITA
Respuesta.Buffer = verdadero
Nombre tenue
…
Fragmento de /app1/buffer__1.asp
Mejor anterior (tiempo de respuesta) = 7,05 ms/página
Tiempo de respuesta = 6,08 ms/página
Diferencia = -0,97 ms (reducción del 13,7%)
El rendimiento ha mejorado mucho. Pero espera, hay algo mejor.
Iniciar buffer a través de la configuración del servidor
Aunque el búfer está habilitado de forma predeterminada en IIS 5.0, debe habilitarse manualmente en IIS 4.0. Ahora busque el cuadro de diálogo Propiedades del sitio y seleccione el botón Configurar en la pestaña Directorio de inicio. Luego seleccione habilitar el almacenamiento en búfer en las opciones de la aplicación. Para esta prueba, la declaración Response.Buffer se eliminó del script.
Mejor anterior = 7,05 ms/página
Tiempo de respuesta = 5,57 ms/página
Diferencia = -1,48 ms (reducción del 21,0%)
Actualmente, esta es la respuesta más rápida que hemos tenido, un 21% menos que nuestro mejor tiempo de respuesta anterior. A partir de ahora, nuestras pruebas futuras utilizarán este tiempo de reacción como valor de referencia.
Revisión y observación
Los búferes son una excelente manera de mejorar el rendimiento, por lo que es necesario configurarlos con los valores predeterminados del servidor. Si por alguna razón la página no puede ejecutar correctamente el búfer, simplemente use el comando Response.Buffer=False. Una desventaja de los buffers es que el usuario no ve nada del servidor hasta que se haya procesado toda la página. Por lo tanto, durante el procesamiento de páginas complejas, es una buena idea llamar ocasionalmente a Response.Flush para actualizar al usuario.
Ahora tenemos una regla más agregada: habilitar siempre el almacenamiento en búfer a través de la configuración del servidor.
¿Debería considerar agregar comentarios a su código ASP?
La mayoría de los desarrolladores de HTML saben que incluir comentarios HTML es una mala idea; en primer lugar, aumenta el tamaño de los datos que se transfieren y, en segundo lugar, simplemente proporcionan a otros desarrolladores información sobre la organización de su página. Pero ¿qué pasa con los comentarios en las páginas ASP? Nunca abandonan el servidor, pero sí aumentan el tamaño de la página, por lo que deben dividirse mediante ASP.
En esta prueba, agregamos 20 comentarios, cada uno con 80 caracteres, para un total de 1600 caracteres.
＜% OPCIÓN EXPLÍCITA
'------------------------------------------------ - ---------------------------------
…20 líneas…
'------------------------------------------------ - ---------------------------------
Nombre tenue
…
/app2/comment_1.asp fragmento
Línea de base = 5,57 ms/página
Tiempo de respuesta = 5,58 ms/página
Diferencia = +0,01 ms (aumento del 0,1%)
Los resultados de la prueba fueron sorprendentes. Aunque los comentarios son casi el doble de largos que el propio archivo, su presencia no tiene un gran impacto en los tiempos de respuesta. Entonces podemos seguir las siguientes reglas:
Siempre que se utilicen moderadamente, las anotaciones ASP tienen poco o ningún impacto en el rendimiento.
¿Debería establecerse explícitamente el idioma predeterminado para la página?
IIS maneja VBScript de forma predeterminada, pero veo que en la mayoría de los casos el idioma está configurado explícitamente en VBScript usando la instrucción <%@LANGUAGE=VBSCRIPT%>. Nuestra próxima prueba examinará qué impacto tiene la presencia de esta declaración en el rendimiento.
＜ %@ IDIOMA=VBSCRIPT % ＞
＜% OPCIÓN EXPLÍCITA
Nombre tenue
…
Fragmento /app2/language1.asp.
Línea de base = 5,57 ms/página
Tiempo de respuesta = 5,64 ms/página
Diferencia = +0,07 ms (aumento del 1,2%)
Como puede ver, incluir declaraciones de idioma tiene un ligero impacto en el rendimiento. por lo tanto:
* Establecer la configuración de idioma predeterminada del servidor para que coincida con el idioma utilizado en el sitio.
* No establezca una declaración de idioma a menos que esté utilizando un idioma no predeterminado.
¿Debería desactivarse el estado de sesión si no es necesario?
Hay muchas razones para evitar el uso del contexto de sesión de IIS, y esas podrían ser su propio artículo. La pregunta que estamos tratando de responder ahora es si cerrar el contexto de sesión cuando la página no lo necesita ayudará a mejorar el rendimiento. En teoría, debería ser sí, porque entonces no hay necesidad de usar la página para crear una instancia del contexto de sesión.
Al igual que el búfer, hay dos formas de configurar el estado de la sesión: mediante scripts y mediante la configuración del servidor.
Cerrar contexto de sesión mediante script
Para esta prueba, para cerrar el contexto de sesión en la página, agregué una declaración de estado de sesión.
＜ %@ ENABLESESSIONSTATE = FALSE % ＞
＜% OPCIÓN EXPLÍCITA
Nombre tenue
…
Fragmento /app2/session_1.asp.
Línea de base = 5,57 ms/página
Tiempo de respuesta = 5,46 ms/página
Diferencia = -0,11 ms (disminución del 2,0%)
Se han logrado buenos avances gracias a un esfuerzo tan pequeño. Ahora mira la segunda parte.
Cerrar el contexto de la sesión a través de la configuración del servidor
Para cerrar el contexto de sesión en el servidor, vaya al cuadro de diálogo Propiedades del sitio. Seleccione el botón Configuración en la pestaña Directorio de inicio. Luego desmarque habilitar estado de sesión en Opciones de aplicación. Ejecutamos la prueba sin la declaración ENABLESESSIONSTATE.
Línea de base = 5,57 ms/página
Tiempo de respuesta = 5,14 ms/página
Diferencia = -0,43 ms (reducción del 7,7%)
Esta es otra mejora significativa en el rendimiento. Por lo tanto, nuestra regla debería ser: cerrar siempre el estado de sesión a nivel de página o aplicación cuando no sea necesario.
¿El uso de Option Explicit cambiará sustancialmente el rendimiento?
Establezca la opción explícita en la parte superior de una página ASP para exigir que todas las variables se declaren en la página antes de su uso. Hay dos razones para esto. Primero, las aplicaciones pueden procesar el acceso a variables más rápido. En segundo lugar, esto evita que accidentalmente utilicemos nombres de variables incorrectos. En esta prueba eliminamos la referencia Option Explicit y la declaración Dim de la variable.
Línea de base = 5,57 ms/página
Tiempo de respuesta = 6,12 ms/página
Diferencia = +0,55 ms (aumento del 9,8%),
Aunque se eliminaron algunas líneas de código de la página, los tiempos de respuesta aún aumentaron. Entonces, aunque el uso de la opción explícita a veces lleva mucho tiempo, tiene un efecto significativo en el rendimiento. Entonces podemos agregar otra regla: use siempre la opción explícita en VBScript.
¿Debería colocarse la lógica de script en subrutinas y áreas de funciones?
Usar funciones y subrutinas es una buena manera de organizar y administrar el código, especialmente cuando un área de código se usa varias veces en la página. La desventaja es que agrega una llamada de función adicional al sistema que hace el mismo trabajo. Otro problema con las subrutinas y funciones es el alcance de las variables. En teoría, es más eficiente especificar variables dentro de un área funcional. Ahora veamos cómo entran en juego estos dos aspectos.
Mover la declaración Response.Write a una subrutina
Esta prueba simplemente mueve la declaración Response.Write a un área de subrutina.
…
LLAMADA a escribirTabla()
SUB tabla de escritura()
Respuesta.Escribir(<html>&_
＜ cabeza ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Correo electrónico:＜ /b ＞＜ /td ＞＜ td ＞ & Correo electrónico & ＜ /td ＞＜ /tr ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Fecha de nacimiento:＜ /b ＞＜ /td ＞＜ td ＞ & Fecha de nacimiento & ＜ /td ＞＜ /tr ＞ & _
＜ /tabla ＞ & _
＜ /cuerpo ＞ & _
＜/html＞)
FINAL SUB
/app2/function1.asp fragmento
Línea de base = 5,57 ms/página
Tiempo de respuesta = 6,02 ms/página
Diferencia = +0,45 ms (aumento del 8,1%)
Como era de esperar, las llamadas a subrutinas generan una sobrecarga adicional en la página.
Mover todos los scripts a subrutinas
En esta prueba, la declaración Response.write y las declaraciones de variables se mueven a un área de subrutina.
＜% OPCIÓN EXPLÍCITA
LLAMADA a escribirTabla()
SUB tabla de escritura()
Nombre tenue
…
fecha de nacimiento tenue
Nombre = Juan
…
Fecha de nacimiento = 1/1/1950
Respuesta.Escribir(<html>&_
＜ cabeza ＞ & _
＜título＞Prueba de respuesta＜/título＞ & _
＜ /cabeza ＞ & _
＜cuerpo＞ & _
＜ h1 ＞Prueba de respuesta＜ /h1 ＞ & _
＜ tabla ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Nombre:＜ /b ＞＜ /td ＞＜ td ＞ & Nombre & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Fecha de nacimiento:＜ /b ＞＜ /td ＞＜ td ＞ & Fecha de nacimiento & ＜ /td ＞＜ /tr ＞ & _
＜ /tabla ＞ & _
＜ /cuerpo ＞ & _
＜/html＞)
FINAL SUB
/app2/function2.asp fragmento
Línea de base = 5,57 ms/página
Tiempo de respuesta = 5,22 ms/página
Diferencia = -0,35 ms (reducción del 6,3%)
¡Muy interesante! Aunque mover variables al alcance de la función agrega una llamada de función adicional, en realidad mejora el rendimiento. Podemos agregar las siguientes reglas:
* En una página, si el código se va a utilizar más de una vez, incluya el código en un área de función.
* Cuando sea apropiado, mueva las declaraciones de variables al alcance de la función.
¿Cuáles son las implicaciones del uso de archivos de inclusión?
Una característica importante de la programación ASP es la inclusión de código de otras páginas. Con esta característica, los programadores pueden compartir funciones en varias páginas, lo que facilita el mantenimiento del código. La desventaja es que el servidor debe ensamblar la página a partir de múltiples fuentes. A continuación se muestran dos pruebas que utilizan archivos Incluir.
Incluir archivos usando código en línea
En esta prueba, se movió un pequeño fragmento de código a un archivo de inclusión:
＜% OPCIÓN EXPLÍCITA
Nombre tenue
…
fecha de nacimiento tenue
Nombre = Juan
…
Fecha de nacimiento = 1/1/1950
%>
＜ !-- #include archivo=inc1.asp -- ＞
/app2/include_1.asp fragmento
Línea de base = 5,57 ms/página
Tiempo de respuesta = 5,93 ms/página
Diferencia = +0,36 ms (aumento del 6,5%)
Esto no es sorprendente. La carga útil se forma utilizando archivos de inclusión.
Utilice Incluir archivos en el área de funciones
Aquí, el código está incluido en una subrutina en un archivo de inclusión. La referencia de inclusión se realiza en la parte superior de la página y llama a la subrutina en la ubicación adecuada en el script ASP.
＜% OPCIÓN EXPLÍCITA
Nombre tenue
…
fecha de nacimiento tenue
Nombre = Juan
…
Fecha de nacimiento = 1/1/1950
LLAMADA a escribirTabla()
%>
＜ !-- #include archivo=inc2.asp -- ＞
/app2/include_2.asp fragmento
Línea de base = 5,57 ms/página
Tiempo de respuesta = 6,08 ms/página
Diferencia=+0,51 ms (aumento del 9,2%)
Esto tiene un mayor impacto en el rendimiento que las llamadas a funciones. Entonces: use Incluir archivos solo cuando el código se comparta entre páginas.
¿Cuánta carga se crea al realizar el manejo de errores?
El manejo de errores es necesario para todas las aplicaciones reales. En esta prueba, se llama al controlador de errores llamando a la función On Error Resume Next.
＜% OPCIÓN EXPLÍCITA
En caso de error Continuar siguiente
Nombre tenue
…
/app2/error_1.asp fragmento
Línea de base = 5,57 ms/página
Tiempo de respuesta = 5,67 ms/página
Diferencia = 0,10 ms (aumento del 1,8%)
Como puede ver, el manejo de errores tiene un precio. Podemos sugerir lo siguiente: Utilice identificadores de errores sólo cuando suceda algo que esté más allá de su capacidad de probar o controlar. Un ejemplo básico es el uso de objetos COM para acceder a otros recursos, como objetos ADO o FileSystem.
¿La configuración de un controlador de contexto tiene algún impacto en el rendimiento?
Cuando ocurre un error, configurar un controlador de contexto en la página permite que el script revierta la acción. Esto se establece mediante una declaración de procesamiento en la página.
＜ %@ TRANSACCIÓN = REQUERIDO % ＞
＜% OPCIÓN EXPLÍCITA
Nombre tenue
…
/app2/transact1.asp fragmento
Línea de base = 5,57 ms/página
Tiempo de respuesta = 13,39 ms/página
Diferencia = +7,82 ms (aumento del 140,4%)
¡ah! Este es verdaderamente el resultado más dramático. Por lo tanto, tenga en cuenta la siguiente regla: utilice el contexto de procesamiento solo cuando dos o más operaciones se realicen como una unidad.
en conclusión
Lo importante de la primera parte de este artículo es la acumulación de muchas pequeñas cosas. Para resaltar este problema, configuré una prueba final en la que hice todas las cosas que habíamos probado antes y que parecían inocuas pero que en realidad tuvieron un efecto negativo. Incluí un montón de declaraciones Response.Write, desactivé el búfer, configuré el idioma predeterminado, eliminé la referencia Option Explicit e inicialicé el controlador de errores.
＜ %@ IDIOMA=VBSCRIPT % ＞
< %
En caso de error Continuar siguiente
Nombre = Juan
…
Fecha de nacimiento = 1/1/1950
Respuesta.Escribir(<html>)
Respuesta.Escribir(＜cabeza＞)
Response.Write(＜título＞Prueba de respuesta＜/título＞)
Respuesta.Escribir(＜/head＞)
Respuesta.Escribir(<cuerpo>)
Respuesta.Escribir(＜h1＞Prueba de respuesta＜/h1＞)
Respuesta.Escribir(＜tabla＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Nombre:＜ /b ＞＜ /td ＞＜ td ＞ &_
Nombre & ＜ /td ＞＜ /tr ＞)
…
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Fecha de nacimiento:＜ /b ＞＜ /td ＞＜ td ＞ &_
Fecha de nacimiento y ＜ /td ＞＜ /tr ＞)
Respuesta.Escribir(＜/table＞)
Respuesta.Escribir(＜/cuerpo＞)
Respuesta.Escribir(＜/html＞)
%>
/app2/final_1.asp fragmento
Línea de base = 5,57 ms/página
Tiempo de respuesta = 8,85 ms/página
Diferencia = +3,28 ms (aumento del 58,9%)
Puede parecer obvio, pero es más importante comprender que el código que colocamos en la página tiene un impacto en el rendimiento. A veces, pequeños cambios en la página pueden aumentar significativamente los tiempos de respuesta.
Resumen de reglas
* Evite el uso excesivo de ASP en línea.
* Siempre concatene respuestas consecutivas. Escriba declaraciones en una sola declaración.
* Nunca utilice funciones contenedoras alrededor de Response.Write para agregar CRLF.
* Si se debe formatear la salida HTML, agregue CRLF directamente dentro de la declaración Response.Write.
* Habilite siempre el almacenamiento en búfer a través de la configuración del servidor.
* Siempre que se utilicen moderadamente, las anotaciones ASP tienen poco o ningún impacto en el rendimiento.
* Establecer la configuración de idioma predeterminada del servidor para que coincida con el idioma utilizado en el sitio.
* No establezca una declaración de idioma a menos que esté utilizando un idioma no predeterminado.
* Utilice siempre la opción explícita en VBScript.
* Desactive siempre el estado de sesión a nivel de página o aplicación cuando no sea necesario.
* Utilice Incluir archivos solo cuando el código se comparta entre páginas.
* En una página, si el código se va a utilizar más de una vez, incluya el código en un área de función.
* Cuando sea apropiado, mueva las declaraciones de variables al alcance de la función.
* Utilice identificadores de errores solo si ocurren condiciones que están más allá de las capacidades de la prueba o control.
* Utilice el procesamiento de contexto solo cuando se realicen dos o más operaciones como una unidad.
Mirando hacia atrás, hay una serie de preguntas que pueden servir como pautas generales:
* Evite la redundancia: no establezca propiedades que ya estén configuradas de forma predeterminada.
* Limitar el número de llamadas a funciones.
* Reducir el alcance del código.