performance - servicios - Encontrar cuellos de botella de rendimiento en un sitio web clásico de servidor asp/sql

en qué consiste un cuello de botella de un proceso industrial o de servicios

Question

Tengo una antigua aplicación clásica de servidor asp / sql que arroja constantemente 500 errores / tiempos de espera a pesar de que la carga no es masiva. Algunas de las consultas DB son bastante intensas, pero nada de lo que debería estar causando su caída.

¿Hay algún buen software que pueda instalar en mi servidor que muestre exactamente dónde están los cuellos de botella en el asp o en el DB?

Answer 1

¿Has intentado ejecutar el Analizador de SQL Server en el servidor? Resaltará cualquier actividad inesperada que golpee la base de datos desde la aplicación, así como la identificación de consultas de bajo rendimiento.

Answer 2

Algunas herramientas que puedes probar:

• HP (anteriormente Mercury) LoadRunner o Performance Center
• Prueba del Centro de aplicaciones de Visual Studio (¿solo Enterprise Editions?)
• Herramienta de estrés de aplicaciones web de Microsoft (también conocido como WAS, también conocido como "Homer"; predecesor de Application Center Test)
• WebLoad
• MS Visual Studio Analyzer si desea rastrear a través del código de la aplicación. Esto puede mostrarle cuánto tiempo espera la aplicación en las llamadas a bases de datos y qué SQL se utilizó. A continuación, puede utilizar el generador de perfiles de SQL para ajustar las consultas.

Answer 3

Si está contento de que las consultas DB sean innecesariamente intensas, tal vez necesite establecer tiempos de espera más adecuados en las páginas que usan estas consultas.

Establezca Server.ScriptTimeout en algo más grande, también puede necesitar establecer el tiempo de espera en los objetos de comando ADO utilizados por el script.

Answer 4

¿Dónde está ocurriendo el tiempo de espera? ¿Está en líneas cuando ASP está conectando / ejecutando sql? Si es así, su problema es con la conexión al servidor de base de datos o al propio db. Cargue el perfilador de SQL en MSSQL para ver cuánto tiempo toman las consultas. Tal vez se deba a bloqueos en la base de datos.

¿Usas transacciones? Si es así, asegúrese de que no bloqueen su base de datos durante mucho tiempo. Asegúrese de usar transacciones en ADO y no en toda la página ASP. También puede ignorar el bloqueo en SQL Selects utilizando la sugerencia WITH (NOLOCK) en las tablas.

Asegúrese de que su base de datos esté optimizada con índices.

Además, asegúrese de estar en contacto con la base de datos durante el menor tiempo posible, es decir, (ejemplo, código que no funciona): conn.open; establecer rs = conn.execute (); rs.close; conn.close Así que guarde los conjuntos de registros en una variable en lugar de recorrer mientras mantiene abierta la conexión a la base de datos. Una buena forma es usar la función GetRows () en ADO.

Siempre cierre explícitamente y establezca objetos ADO a nada. Esto puede causar que la conexión con el DB permanezca abierta.

Habilite la agrupación de conexiones.

Cargue las constantes de ADO en global.asa si las está usando

No almacene ningún objeto en los ámbitos de sesión o aplicación.

Actualice a las últimas versiones de los paquetes de servicio ADO, MDac, SQL Server, etc.

¿Estás seguro de que el servidor puede manejar la carga? Tal vez actualizarlo? ¿Es en alojamiento compartido? Tal vez su aplicación no es el problema.

Es bastante simple medir el rendimiento de un script al sincronizarlo desde la línea 1 a la última línea. De esta manera puede identificar páginas de ejecución lenta.

Answer 5

Así es como lo abordaría.

1. Mira las tareas en ejecución en el servidor. ¿Qué ocupa más tiempo de CPU: SQL Server o IIS? La mayoría de las veces, será un servidor SQL y ciertamente suena de esa manera en función de su publicación. Es muy raro que cualquier aplicación ASP en realidad haga un montón de procesamiento en el lado ASP de las cosas en comparación con los lados COM o SQL.

2. Use el Analizador de SQL para verificar todas las consultas que llegan al servidor de la base de datos.

3. Trate primero con la fruta más baja. En general, tendrá algunas consultas "problemáticas" que afectan a la base de datos con frecuencia y matan mucho tiempo. Trata con estos. (Un truismo en el desarrollo de software es que el 10% del código mastica el 90% del tiempo de ejecución ...)

Además de analizar los costos de consulta con SQL Profiler y Query Analyzer / SQL Studio y realizar el trabajo de detección de rendimiento de SQL normal, es posible que también desee comprobar si las llamadas a la base de datos devuelven cantidades desproporcionadas de datos a su código ASP. He visto casos en los que aparecían consultas inofensivas que devolvían GRANDES cantidades de datos innecesarios a ASP: el clásico ("seleccionar * del nombre de tabla") consulta escrita por programadores perezosos / inexpertos que devuelve 10.000 filas enormes cuando el programador realmente solo necesitaba 1 campo de 1 fila. La razón por la que menciono este caso especial es porque este tipo de consultas a menudo tienen tiempos de ejecución bajos y bajos costos de consulta en el lado SQL de las cosas y, por lo tanto, pueden pasar desapercibidas.