David Olshefski, Jason NiehSIGMetrics/Performance, ACM, Junio 2006, pp.

26-30

Understanding the Understanding the Management of Client Management of Client

Perceived Response TimePerceived Response Time

Paper analizado por:• Héctor Manuel Lara García• Mónica Villalpando Pérez

14 de Febrero del 2007Facultad de Ingeniería, UABC, Ensenada

ArquitecturaArquitectura

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

Percepción del usuario Percepción del usuario (Pageview)(Pageview)

Factores de tiempo que Factores de tiempo que intervienen en la transmisiónintervienen en la transmisión

• Tconn: Latencia de conexión

• Tserver: Latencia del servidor para procesar archivos, llamados, CGI’s.

• Ttransfer: Tiempo requerido para transferir del servidor al

cliente

• Trender: 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.

ModeladoModelado

Cliente - Servidor

Grafo de eventos-nodos

Latencias a manejarLatencias 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

Como manejar estas Como manejar estas latenciaslatencias

Problema de Latencia

Solución

Tconn: solicitar la conexión

Fast SYN retransmisión

Tconn: aceptar la conexión

Fast SYN/ACK retransmisión

Ttransfer: objetos embebidos

Embedded object rewrite (reducción de tamaño del objeto)

Ttransfer: objetos embebidos

Embedded object removal (eliminar el objeto)

Manejo de Latencia al Manejo de Latencia al conectarse (Tconn)conectarse (Tconn)

El servidor descarta la conexión por estar saturado

Manejo de la latencia al Manejo de la latencia al conectarse (Tconn)conectarse (Tconn)

El cliente no se recibe ACEPTACION de conexión por parte del servidor

Base ExperimentalBase Experimental

Servicio Parametros

Apache 2.0.55 1200 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.3 Default configuration, except that max.connections=1000 for the persistent connections to Tomcat

Otros Workload with 200 clients (which keeps DBserver at 60% utilization)

1200

1500-2000

1000

Distribución de tiempo de Distribución de tiempo de respuestarespuesta

Ideal (bajo RTT y 0 perdidas)

Distribución de tiempo de Distribución de tiempo de respuestarespuesta

RTT y % de perdida de paquetes mas apegado a

la realidadCarga = 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.

Modificando la latencia de re Modificando la latencia de re conexiónconexión

Regla RLM:IF IP.SRC == *.*.*.* THEN FAST SYN/ACK GAP 500ms

Mejora significativa en retransmisiones SYN/ACK cada 10ms

Modificando la cargaModificando 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.

Modificando la carga y el Modificando la carga y el control de admisióncontrol de admisión

Apache MaxClients = 400Users = 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

Modificando la carga y el Modificando la carga y el control de admisión control de admisión asignando prioridadasignando prioridad

Users= 5501/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.

Modificando la carga y el Modificando la carga y el control de admisión control de admisión asignando prioridadasignando 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 reanudanRegla RLM:

IF IP.SRC == *.*.*.* THEN FAST SYN + SYN/ACK GAP 500msIF IP.SRC != 10.4.*.* AND RT_HIGH >3.0 THEN DROP SYN HALT FAST SYN

Manejando la latencia de Manejando la latencia de transferenciatransferencia

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.68s2.85s2.19s

Manejando la latencia de Manejando la latencia de transferenciatransferencia

Se incrementa # de usuarios a 550Con 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

ConclusionesConclusionesEs 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

servidorPropone mejoras para:

TconnFast SYNFast SYN/ACK

TtransferEmbedded removeEmbedded rewrire

Al fin

FinFin