Presentación tema 4 de la asignatura "Servidores web" del Máster Universitario en Desarrollo de Aplicaciones y Servicios Web. sobre pruebas a servicios web

1. AISI
Servidores Web
Pruebas

2. SW pruebas
rendimiento

3. SW pruebas
Destinadas a descubrir problemas por
●
Falta de recursos: red (ancho de
banda), sistemas (hw o sw) o apps
(diseño,...)
●
Confictos HW o SW (que conduzcan a
degradación del rendimiento)
Objetivos:
●
Conocer cómo se comporta el servicio
conforme aumenta la carga
●
Recopilar información para mejorar el
rendimiento
introducción

4. SW pruebas
¿El tiempo de respuesta del servidor se
degrada a un punto donde es apreciable
e Inaceptable?
¿En qué punto (en términos de
usuarios, transacciones o carga de
datos) el rendimiento se vuelve
inaceptable?
¿Qué componentes del sistema son
responsables de la degradación del
rendimiento?
¿Cuál es el tiempo de respuesta
promedio para los usuarios bajo diversas
condiciones de carga?
Objetivos

5. SW pruebas
¿La degradación del rendimiento tiene
impacto sobre la seguridad del sistema?
¿La confiabilidad o precisión de la
webapp resulta afectada conforme crece
la carga sobre el sistema?
Qué sucede cuando se aplican cargas
que son mayores que la capacidad
máxima del servidor?
¿La degradación del rendimiento tiene
impacto sobre los ingresos de la
compañía?
Objetivos

6. SW pruebas
¿La degradación del rendimiento tiene
impacto sobre la seguridad del sistema?
¿La confiabilidad o precisión de la
webapp resulta afectada conforme crece
la carga sobre el sistema?
¿Qué sucede cuando se aplican cargas
que son mayores que la capacidad
máxima del servidor?
¿La degradación del rendimiento tiene
impacto sobre los ingresos de la
compañía?
Objetivos

7. SW pruebas
Determinar cómo responderá la webapp
y su backend en condiciones variables de
carga. Variables importantes:
●
N, número de usuarios concurrentes
●
T, número de transacciones en línea
por unidad de tiempo
●
D, carga de datos procesados en cada
transacción
●
R, respuesta promedio
●
Tm, tiempo promedio para procesar
una transacción
●
Dm, tiempo promedio para descargar
una unidad estandarizada de datos
Prueba de carga

8. SW pruebas
Determinar si una disminución abrupta
en el rendimiento puede rastrearse en
una combinación específica de N, T y D.
El rendimiento global, P, se calculará:
P= NxTxD
Ejemplo: En un momento dado, 20 000 usuarios concurrentes envían una
solicitud (una transacción, T) una vez cada 2 minutos en promedio. Cada
transacción requiere que la webapp descargue un nuevo artículo que
promedia 3 Kb de longitud. Por tanto, el rendimiento global puede calcularse
como:
P = [20 000 x 0.5 x 3Kb]/60= 500 Kbytes/s = 4 megabits por segundo
Prueba de carga

9. SW pruebas
●
El objetivo de la prueba de esfuerzo es
comprender de mejor manera como falla
un sistema a medida que es forzado más
allá de sus límites operacionales.
●
¿El sistema se degrada “suavemente” o
el servidor se apaga conforme la
capacidad se supera?
●
¿El servidor pone en cola los recursos
solicitados y vacía la cola una vez que
disminuye la demanda de capacidad?
●
Si el sistema falla, ¿cuánto tiempo
tardará en recuperarse?
Prueba de esfuerzo

10. SW pruebas
●
¿Qué valores de N, T y D fuerzan el fallo
del entorno servidor? ¿Cómo se
manifiesta la falla? ¿Se envían
notificaciones automáticas al personal de
apoyo técnico en el sitio servidor?
●
A una variación de las pruebas de
esfuerzo en ocasiones se le conoce como
prueba pico/rebote (spike/bounce)
Prueba de esfuerzo

11. SW pruebas
●
¿La webapp es completamente
compatible con el backend?
•¿Las medidas de seguridad del sistema
(por ejemplo, firewalls o cifrado) permiten
a la webapp ejecutarse y atender a los
usuarios sin interferencia o degradación
del rendimiento?
●
¿La webapp se integró adecuadamente
con el software de base de datos?
Prueba de configuración

12. SW pruebas
●
sondear las vulnerabilidades y
debilidades, tanto en el lado del cliente
como en el backend
●
¿Los datos comunicados entre el cliente
y el servidor son vulnerables al spoofing?
●
¿DoS?
●
¿Accesos? ¿A la base de datos?
●
…
●
Las pruebas de seguridad deben
diseñarse para sondear cada una de
estas tecnologías de seguridad con la
intención de descubrir agujeros
Prueba de seguridad

13. SW pruebas
●
Instalación: apt-get install apache2-utils
●
Uso:
ab -n 100 -c 10 http://miservidor/
n: conexiones
c: concurrencia
●
¿Qué nos proporciona?
.- tiempo de servicio
.- cantidad de datos que se transmiten
.- tiempo empleado en conectar con el
servidor, de procesamiento de la petición
.- % peticiones servidas en cierto
tiempo
ab

14. SW pruebas
●
Instalación: apt-get install apache2-utils
●
Uso:
ab -n 100 -c 10 http://miservidor/
n: conexiones
c: concurrencia
●
¿Qué nos proporciona?
.- tiempo de servicio
.- cantidad de datos que se transmiten
.- tiempo empleado en conectar con el
servidor, de procesamiento de la petición
.- % peticiones servidas en cierto
tiempo
ab

15. SW pruebas
●
Instalación: apt-get install siege
●
Uso:
siege -t 60s -c 100 -b -q http://miservidor/
t: tiempo de duración de la prueba
c: conexiones concurrentes
b: obliga a no tener ningún retraso entre cada usuario simulado
(modo benchmark)
q: elimina la salida
●
¿Qué nos proporciona?
●
Transactions: 7718 hits
●
Availability: 100.00 %
●
Elapsed time: 59.83 secs
●
Data transferred: 0.32 MB
●
Response time: 0.77 secs
●
Transaction rate: 129.00 trans/sec
●
Throughput: 0.01 MB/sec velocidad transporte de datos→
●
Concurrency: 98.97
●
Successful transactions: 7718
●
Failed transactions: 0
●
Longest transaction: 2.74
●
Shortest transaction: 0.02
siege

16. AISI
administración
e implantación
internet
en
de servicios