Conferencia presentada por Sergio Cedillo.

1. Ya eres parte de la evolución
Liquid Day
Las Pruebas de Desempeño
desenmascaradas
ing. Sergio Cedillo
t: @chaakceco, m: ing.sergio.cedillo@gmail.com
#sgnext

2. La expectativa en tiempos de
respuesta…
Qué % de usuarios espera la respuesta en….
< 2 segs?
49%
< 1 seg?
30%
Ya (msegs)?
18%

3. Y la realidad tan común…
• …Espere un momento por favor

4. Porqué me debe de importar?
• Perdida de Oportunidades
• Perdida de Clientes
• Reducción en Ventas
• Reducción en Ingresos (Ej. Recaudadora de impuestos)
• Pago de Multas por Incumplimiento a Contratos
• Mala percepción de Calidad
• Paro de Servicios
• Alto Costo para mejorar los servicios
• Etc., etc.

5. Pruebas de Desempeño
ó
Ingeniería de Desempeño

6. Pruebas ¿de Qué?
• En General de “Desempeño”…
• En Particular:
• Carga
• Volumen
• Stress/Contención
• Benchmark
• Capacity
• Soak
• Profiling
• Y también de Desempeño
• Software/Hardware
• Tip: ¿Cuál prueba necesito? – Pensar en el Objetivo

7. Tan fuerte como el eslabón más
débil

8. Muchas las fuentes de problemas
POR CAPA
• Desde el GUI
• Los Balanceadores
• El Web Server
• La capa J2EE
• La capa de Datos
• La red
POR ORIGEN
– El Código
– El Diseño
– La Arquitectura
– El Monitoreo
– La falta de Pruebas
– El Software Base
– El Hardware
– Falta de
Planeación de
Capacidad
POR FACTORES
EXTERNOS /
INFORTUITOS
– Una Campaña de
marketing
subestimada
– Un Concierto
súper esperado
– Factores sorpresa
– Un ataque de
Anonymous
– Etc., etc.

9. El efecto Búfalo…

10. El caso de Sistemas NO Informáticos:
• El Ejemplo de las Cajas del Banco:
• Número de Operaciones por Cliente
• Diversa Complejidad de Operaciones
• Distinta velocidad de los Cajeros
• Demanda muy variable por Hora, Día del mes,
de la semana, Quincena, etc.
• También afectado por sistemas informáticos,
pero no necesariamente
• Del Supermercado, de una Avenida, etc., etc.

11. El comportamiento Constante
Carga
0
0.5
1
1.5
2
2.5
10
20
30
40
50
60
70
80
El Comportamiento Constante
Carga

12. El comportamiento Lineal
Carga
0
1
2
3
4
5
6
7
8
9
100
110
120
130
140
150
160
El Comportamiento Lineal
Carga

13. El comportamiento Exponencial
Carga
0
1000
2000
3000
4000
5000
6000
7000
200
210
220
230
240
250
260
El Comportamiento Exponencial
Carga

14. Es el número de usuarios
realmente lo que importa?
• NO importa cuántos clientes estén esperando en la
sala del Banco, o en llenando su carrito en el súper
• Lo que importa es la capacidad de atender a los
clientes al momento de llegar a las cajas

15. Tip: Pensar mejor en Throughput
• Throughput:
• (TRANSACCIONES x Unidad de Tiempo)
• Típicamente:
• 350 hits/seg
• 1500 compras/minuto
• 150 consultas/seg
• Etc.,etc.

16. Así que, ¿En qué momento empiezo a
probar para el desempeño?
• La disyuntiva de siempre:

17. Desde el Inicio…
• Aún no están construidos todos los elementos que
contribuyen al desempeño,
• Inestabilidad en la Aplicación
• NO está disponible el hardware real,
• NO está en ambiente productivo,
• NO está afinado el middleware, etc.
• La BD no está suficientemente poblada,
configurada, afinada, etc.
• El middleware, etc., etc….

18. Hasta el final…
• Ya está toda la infraestructura disponible, ya está
todo el código terminado, ya está probada y
estable la aplicación, pero…
• Podría ser demasiado tarde para corregir problemas de
diseño ó de arquitectura
• Ya no queda tiempo de hacer cambios
• Ya no queda tiempo de hacer afinación (tuning)
• Ya no queda tiempo siquiera de hacer pruebas

19. Tip: Pero Antes que nada:
El Análisis de Carga
• Para entender los múltiples escenarios
• Para evitar caer en lo irreal ó lo imposible
• Para emular lo más cercano posible escenarios reales
• Para comunicarse mejor con los dueños de la
información
• Para entender los perfiles de usuarios requeridos: El
operador, el administrador, el usuario final ó los
usuarios finales (El navegador, el comprador, el
comparador, etc.)
• Sustentado lo más posible en estadísticas históricas

20. Tip: Comenzar lo más Temprano
posible
• Con buenas prácticas
de Diseño y
Codificación
• Con herramientas de
perfilado
• Con el uso de stubs
• Con pruebas por
etapas
• Con herramientas de
Simulación de Carga
Heterogeneous Environments
Nube Pública
Nube Privada
Data Warehouse Mainframe
Enterprise
Service Bus
LDAP
File
systems
Collaboration
Web/
Internet
Servicios
de Ruteo
Servicios
de Terceros Portales
Proveedores de
Contenido
EJBs
Servicios
Compartidos
Archivos
Business
Partners
Servicios de
Mensajería

21. Las opciones del mercado
• Las propietarias
(HP, IBM, MS VSTS, Compuware, Borland, Apica)
• Las Open Source
(The Grinder, Gatling, Tsung, Jmeter, OpenSTA)
• Las de Nube
(HP, IBM, Microsoft, WorkSoft, etc)

22. Es simple... y complejo…
Corrección:
• …más bien es muy simple hacer una Prueba de
Desempeño
• Con las herramientas de hoy es muy sencillo
• …pero también es muy difícil hacer una buena
Prueba de Desempeño:
• Por lo difícil que es replicar exactamente un ambiente
real de producción.
• Por la aleatoriedad del comportamiento de los sistemas
de producción
• Es suficiente el 20/80?, ó el 30/90? ó el 40/95?

23. NO a:
• Resolver de primera mano los problemas de
desempeño con “El maquinazo”
• Relegar las pruebas de Desempeño hasta el final
• Ejecutar una prueba de Desempeño sin tener Claro
el Objetivo
• Ejecutar una prueba de Desempeño sin haber
hecho el Análisis de Carga esperado
• Sólo considerar el # de Usuarios Concurrentes

24. SI a:
• Dedicar suficiente tiempo a Analizar, Diseñar y
Ejecutar las Pruebas de Desempeño
• Probar Temprano y Seguido
• Contemplar el uso de herramientas complementarias
(monitoreo, profiling, descomposición de
transacciones)
• Incluir un equipo interdisciplinario comprometido con
el objetivo de mejorar (No de echar culpas)
• Educación para mejorar la experiencia
• Promover la cultura del desarrollo orientado para el
Desempeño Aplicativo.

25. Tiempo para una pequeña…

26. ¿Preguntas?
Gracias por su atención e Interés - Datos de Contacto:
ing.sergio.cedillo@gmail.com
@chaakcheco
55.5104.1695