Es lo que me ha estado diciendo el servidor de pruebas. Esa semana la hemos dedicado a probar toda la infraestructura que hemos creado para nuestro portal, no solo que no haya “petardazos”, además la hemos realizado una gran cantidad de pruebas de carga para conocer los límites del portal y descubrir posibles errores y mejoras en el código.
Antes de ponernos a realizar las pruebas, me preocupé por investigar primero ¿Cómo las debíamos hacer?, ¿Qué debemos probar? Y ¿Qué íbamos a esperar de ellas?.
Navegando un poco he encontrado una guía de Microsoft imprescindible y completísima: Improving .NET Application Performance and Scalability. Incluye recomendaciones de diseño, de programación, de configuración, nos explica cómo monitorizar el portal, cómo configurarlo, etc.. Además incluye varios checklist bastante útiles.
Además encontré a unos personajes muy interesantes que me proporcionaron información en sus blogs acerca de que herramientas podía utilizar, cómo utilizarlas, sus experiencias, etc.
Alik Levin’s tiene un blog muy completo sobre performance y scalability. Además de un post “Do You Really Need A Distributed Architecture?” acerca de si realmente estamos seguro de que SOA sea la mejor solución para nuestro proyecto.
Patrick Mac Kay, un experto en testear aplicaciones tiene un blog en el que nos cuenta sus experiencias, después de leerlos solo puedes decir “vaya nivel”.
Las herramientas que hemos utilizados han sido:
· El módulo de pruebas de Visual Studio 2008
· Fiddler (How to de José Manuel)
Como resultado, esta semana hemos conseguido los siguiente:
· Hemos encontrado pequeños errores de programación y hemos mejorado algunos módulos.
· Disponemos de la configuración necesaria para los requisitos del proyecto.
· Hemos creado nuestros check list de desarrollo para el proyecto.
· Conocemos los límites y condiciones idóneas del portal.
· Sabemos cómo monitorizarlo y cómo actuar en caso de tener problemas.
· Nos hemos divertido un rato.
Comentaros que este proyecto, todavía está en una de las fases iniciales, es decir no hemos esperado hasta el final para realizar las pruebas. Esto es importante en el sentido que podemos encontrar antes las “sorpresas”, vamos preparando las pruebas unitarias para futuras pruebas y podemos ir tuneando el sistema y el portal para que tenga un rendimiento aceptable en condiciones de alto consumo/uso.
Hola a Todos. Bueno nada como un domingo un poco desocupado como para responder preguntas. Se me ha preguntado