david olshefski, jason nieh sigmetrics/performance, acm, junio 2006, pp. 26-30 understanding the...
TRANSCRIPT
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