| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos |
Artículo "Consejos sobre pruebas de rendimiento y optimización"
En este útil artículo, Floyd Marinescu (autor del popular libro "EJB Design Patterns") nos enseña cómo hacer que nuestra aplicación Web tenga un alto rendimiento incluso bajo una gran carga de usuarios y de datos, basándose para ello en su experiencia como arquitecto jefe del portal TheServerSide.com, el cual recibe más de dos millones de visitas diarias.
Artículo "Consejos sobre pruebas de rendimiento y optimización" (continuación)
3. PRUEBAS DE CARGA Y ESCALABILIDAD. El propósito de las pruebas de carga y escalabilidad es asegurar que la aplicación tendrá un buen tiempo de respuesta durante los picos de uso. También se puede evaluar cómo la aplicación se comportará a lo largo del tiempo (conforme el sitio Web contenga cada vez más información en la base de datos). Para comenzar a probar, escriba algunos guiones de prueba que llenen la base de datos con una cantidad promedio de datos. Ejecute las pruebas de rendimiento y mida el tiempo de respuesta. A continuación, llene la base de datos con una cantidad extremada de datos (3 o 4 veces más datos de los que se prevee que haya en 3 años). Ejecute de nuevo las pruebas de rendimiento. Si los tiempos de respuesta son significativamente mayores para la segunda prueba, entonces algo falla. Para ejecutar las pruebas de rendimiento, deberá simular el uso del servidor con diferentes cargas. Como regla general, yo simulo carga baja (de uno a cinco usuarios concurrentes), carga media (de 10 a 50 usuarios concurrentes) , carga alta (100 usuarios concurrentes) y carga extrema (1000 o más usuarios concurrentes). Nótese que esos números son arbitrarios y dependen de las necesidades del negocio. Además, simular 10 usuarios concurrentes con software de pruebas de carga no es representativo de 10 personas, ya que cada “robot” en la prueba de carga puede esperar sólo milisegundos antes de acceder de nuevo al servidor. Por lo tanto, usar un probador de carga para simular 10 usuarios es probablemente representativo de los comportamientos de navegación en el web de 30 o 40 personas. Una vez ha probado estos tres niveles de carga, puede comparar tiempos medios de respuesta para ver si su sistema es escalable, es decir, si el tiempo de respuesta aumenta linealmente. 4. INTERPRETANDO LOS RESULTADOS. La parte divertida de este proceso es interpretar los resultados de las pruebas de carga. Examinemos algunas de las diferentes posibilidades: El tiempo de respuesta aumenta demasiado cuando la base de datos se llena mucho El tiempo de respuesta no debería aumentar demasiado si se pasa de una base de datos con 100 filas en sus tablas a una con 50,000 filas. La tecnología de indexado de bases de datos hace que hallar una fila en una tabla tarde unos cuantos milisegundos, incluso si hay cientos de miles de filas. Por lo tanto, si el tiempo de respuesta aumenta mucho después de pasar de una base de datos de tamaño moderado a una de tamaño extremo, entonces probablemente aún no se han indexado las columnas apropiadas. El tiempo de respuesta aumenta exponencialmente cuando aumenta la carga Si el sistema se vuelve inutilizable conforme se aumenta el número de usuarios concurrentes, entonces el sistema no es escalable. Interpretar estos resultados es difícil pues el problema podría ser causado por el hardware, la configuración de despliegue, la arquitectura, etc. Asegúrese de que observa los recursos del servidor durante las pruebas: Observe los requerimientos de memoria. Observe el uso de CPU. Si la CPU se usa demasiado, se necesita un procesador más rápido o más procesadores. Si la CPU se usa poco, entonces probablemente el problema esté en la entrada/salida. Compruebe las conexiones de bases de datos, el número de threads (hilos) que se ejecutan y la configuración de la red en las máquinas de prueba. Si el problema no se resuelve después de comprobar la configuración, de verificar que la lentitud no se debe a un cuello de botella del hardware y de revisar rápidamente la arquitectura buscando código para optimizar, es el momento de ejecutar un perfilador de código.
Ir a la página: 1 2 3 4 Siguiente >>
Versión para imprimir
| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos| |