David Olshefski, Jason Nieh SIGMetrics/Performance, ACM, Junio 2006, pp. 26-30 Understanding the Management of Client Perceived Response Time Paper analizado.

Presentación del tema: "David Olshefski, Jason Nieh SIGMetrics/Performance, ACM, Junio 2006, pp. 26-30 Understanding the Management of Client Perceived Response Time Paper analizado."— Transcripción de la presentación:

1 David Olshefski, Jason Nieh SIGMetrics/Performance, ACM, Junio 2006, pp. 26-30 Understanding the Management of Client Perceived Response Time Paper analizado por: Héctor Manuel Lara García Mónica Villalpando Pérez 14 de Febrero del 2007 Facultad de Ingeniería, UABC, Ensenada

2 Arquitectura Aplicación independiente no invasiva. No requiere modificaciones en el servidor Opera del lado del Servidor Conexión directa al servidor que no afectada por condiciones Trabaja a nivel de paquete de red Mide el tiempo de respuesta percibido por el cliente. Captura de forma pasiva y los reenvía usando el modelo TCP

3 Percepción del usuario (Pageview)

4 Factores de tiempo que intervienen en la transmisión T conn : Latencia de conexión T server : Latencia del servidor para procesar archivos, llamados, CGIs. T transfer : Tiempo requerido para transferir del servidor al cliente T render : tiempo requerido por el navegador para procesar la respuesta, ya sea HTML o una imagen. El navegador puede hacer más de una conexión al servidor donde se hospeda el sitio y así bajar varios elementos al mismo tiempo.

5 Modelado Cliente - Servidor Grafo de eventos-nodos

6 Latencias a manejar Cliente - Servidor Tconn (Retardo en la conexión) Solicitud de conexión descartada por el servidor (SYN) al inicio Aceptación de conexión no recibida por el cliente Ttransfer (Retardo en la transferencia) Objetos embebidos

7 Como manejar estas latencias Problema de LatenciaSolución Tconn: solicitar la conexiónFast SYN retransmisión Tconn: aceptar la conexiónFast SYN/ACK retransmisión Ttransfer: objetos embebidosEmbedded object rewrite (reducción de tamaño del objeto) Ttransfer: objetos embebidosEmbedded object removal (eliminar el objeto)

8 Manejo de Latencia al conectarse (Tconn) El servidor descarta la conexión por estar saturado

9 Manejo de la latencia al conectarse (Tconn) El cliente no se recibe ACEPTACION de conexión por parte del servidor

10 Base Experimental ServicioParametros Apache 2.0.551200 server threads Tomcat 5.5.12 Pool of 1500 to 2000 threads to HTTP server Pool of 1000 persistent JDBC connections to database server Mysql 1.3Default configuration, except that max.connections=1000 for the persistent connections to Tomcat OtrosWorkload with 200 clients (which keeps DBserver at 60% utilization) 1200 1500-2000 1000

11 Distribución de tiempo de respuesta Ideal (bajo RTT y 0 perdidas)

12 Distribución de tiempo de respuesta RTT y % de perdida de paquetes mas apegado a la realidad Carga = 200 usuarios. La distribución se mueve a la derecha Muestra un pico después de los 3 segundos Debido a la primer o segunda conexión después de haber tenido una perdida de SYN o SYN/ACK en la red.

13 Modificando la latencia de re conexión Regla RLM: IF IP.SRC == *.*.*.* THEN FAST SYN/ACK GAP 500ms Mejora significativa en retransmisiones SYN/ACK cada 10ms

14 Modificando la carga 550 clientes (antes 200) - Causando una carga de trabajo pesada El tiempo de respuesta promedio percibido por el cliente se incrementó a 5 segundos en comparación con1.9segundos de la grafica anterior (con 200 clientes). Las perdidas de SYN continua igual, ya que solo se pierden en la red y no en el servidor.

15 Modificando la carga y el control de admisión Apache MaxClients = 400 Users = 550 El pico a los 5 segundos representa aquellas peticiones cuyo SYN fue descartado y pasaron 3 segundos de espera en una de las conexiones al servidor Aunado a los 2 seg. de latencia mostrados en la grafica normal El pico a los 8s, representa aquellas conexiones que esperaron 3s en ambas conexiones al servidor El pico a los 21s representa aquellos clientes que tuvieron falla en la conexión

16 Modificando la carga y el control de admisión asignando prioridad Users= 550 1/3 = High priority clients (10.4.*.*) 2/3 = Low priority clients Regla RLM: IF IP.SRC != 10.4.*.* AND RT_HIGH > 3.0s THEN DROP SYN Descartando clientes de baja prioridad cuando los de alta prioridad exceden su tiempo de espera. 184 HP clients RT = 3segundos 366 LP clients Pico 21s indica las conexiones fallidas de estos clientes.

17 Modificando la carga y el control de admisión asignando prioridad Utilizando fast SYN y fast SYN/ACK, ayuda a los clientes de baja prioridad Cuando RT_HIGH > 3s, se empiezan a descartar las conexiones de baja prioridad temporalmente. Cuando RT_HIGH <3s, se reanudan Regla RLM: IF IP.SRC == *.*.*.* THEN FAST SYN + SYN/ACK GAP 500ms IF IP.SRC != 10.4.*.* AND RT_HIGH >3.0 THEN DROP SYN HALT FAST SYN

18 Manejando la latencia de transferencia Users= 200 (carga moderada) Con 3 grupos de usuario Los que tienen RTT=160ms y RT=3s Los que tienen RTT=220ms y RT=4s Los que tienen RTT=300ms y RT=5s Se eliminaron objetos Ninguna pagina tiene mas de 11 objetos El incremento en RT a partir de 2 objetos, se debe a que en ese momento, se abre la segunda conexión y además de tener Tconn: También existe un slow start de TCP ya que aprox. 18% de las veces, el segundo objeto es una imagen grande (.gif de 256kb). 75% de las veces, la pagina contiene 9 objetos 18% 10 o mas objetos Regla RLM: IF IP.SRC == *.*.*.* THEN REMOVE EMBEDS 3.68s 2.85s 2.19s

19 Manejando la latencia de transferencia Se incrementa # de usuarios a 550 Con 3 grupos de usuario Los que tienen RTT=160ms y RT=3s Los que tienen RTT=220ms y RT=4s Los que tienen RTT=300ms y RT=5s Se reescriben los objetos Objetos grandes son minimizados para una mas rápida transmisión Al transferir por medio de la 2da conexión, la imagen grande incrementa la latencia Al reescribir el objeto. Reescribiendo el objeto se logra mantener un RT constante para cada grupo de usuario sin importar el tamaño del objeto Regla RLM: IF RT > 2s THEN REWRITE EMBEDS

20 Conclusiones Es importante medir el tiempo de respuesta desde el lado del cliente. Remote Latency-based Management (RML) No requiere cambios drásticos a la configuración actual del servidor ni del cliente. Las métricas se hacen desde el lado del servidor Propone mejoras para: Tconn Fast SYN Fast SYN/ACK Ttransfer Embedded remove Embedded rewrire Al fin

21 Fin