31/01/2008 02:56 por
zorry
Bueno, pues hemos conseguido averiguar y solucionar los problemas que teníamos con nuestra aplicación.
Al estresar nuestra aplicación, con 20 usuarios concurrentes, habíamos encontrado que sólo un 10% de las pruebas conseguían finalizar correctamente. Con lo que nos ponemos con la ingeniería forense:
- Comprobamos que nuestra aplicación web no sea el causante de los problemas. En principio, no lo parece. El consumo de CPU es del orden del 2% y la de memoria algo alta, pero nuestra aplicación siempre ha sido un poco "hambrienta", unos 100 megas. Pero la máquina debería ser capaz de aguantar la carga de proceso sin problemas.
- Descartado nuestro frontal, vamos a comprobar cómo va el servidor de CRM. De nuevo, parece que todo va como debería, muy poco consumo de CPU (2%) y memoria otra vez contenido (aproximadamente 100 megas también).
- Descartamos el CRM, con lo que nos queda inspeccionar el servidor de SQL Server. Entramos en la máquina y ya notamos que hay algo que no va todo lo bien que debiera: La CPU está en torno al 98% de carga (de un quad core) y la memoria está disparada, aproximadamente tiene unos 6 Gb de memoria el servicio de SQL. Una vez paramos las pruebas de carga, el consumo de CPU baja al 0%. Parece que tenemos fichado al culpable. Ahora vamos a ver cómo lo solucionamos.
Decidimos volver a lanzar las pruebas de carga, pero esta vez con un SQL Profiler, de manera que podamos trazar las consultas realizadas al servidor SQL. Tras unos minutos capturando tráfico, vemos que hay algunas consultas que saturan la CPU. Con lo que vamos a ver de que manera las optimizamos.
Cargamos Database Engine Tuning Advisor, una herramienta de SQL Server 2005, e introducimos el archivo de traza capturado antes. Le decimos que tiene que inspeccionar la base de datos de CRM, y se pone a la tarea. Tras un rato ejecutando y analizando nuestro conjunto de pruebas, nos sugiere crear una serie de índices y estadísticas sobre bastantes tablas, estimando la mejora en un 90% aproximado. Posteriormente la herramienta nos permite aplicar o salvar los cambios, y elegimos salvarlos en un archivo sql para poder aplicarlo en todos los entornos.
Pero nos queda la preocupación de si será recomendable modificar la base de datos de CRM, ya que no tenemos control sobre ella, al estar la estructura de esta base de datos mantenida por el propio CRM. Pero tras investigar un poco, encontramos en este artículo lo que necesitábamos: Está soportado crear índices siempre y cuando no sean índices únicos.
Así que aplicamos los cambios sobre la estructura de base de datos, y volvemos a realizar la prueba. Y los resultados no pueden ser más esperanzadores, ya obtenemos más de un 90% de pruebas correctas, y ahora el servidor es capaz de procesar más del doble de peticiones http por minuto!
299bf008-fd84-4c0e-9fbb-5bf3b89e48f4|0|.0