Problemas de rendimiento de la aplicación y latencia

El impacto de la latencia de la capa de comunicación suele estar subestimado cuando se trata de solucionar problemas de rendimiento de las aplicaciones, pero una comprensión correcta es fundamental si se quiere dirigir los esfuerzos hacia soluciones prácticas.

Primero, por latencia de la capa de comunicación me refiero al tiempo que tarda un paquete en ir del sistema local al sistema remoto y viceversa. El mayor factor de la latencia de la capa de comunicación es la distancia, al menos para los anfitriones separados geográficamente. El otro componente principal es el número de dispositivos entre los hosts locales y remotos que procesan los paquetes; esto incluye cosas como enrutadores y cortafuegos. El ancho de banda de los enlaces juega un papel importante pero no tan grande como la mayoría de la gente piensa. El ancho de banda afecta el retardo de inserción, es decir, el tiempo que toma poner un paquete en el cable pero la señal en el cable viaja a una velocidad basada en el medio y no en el ancho de banda. Para el resto de esta discusión sólo usaré la latencia cuando me refiera a la latencia de la capa de comunicación.

Para demostrar cómo afecta la latencia a su aplicación, digamos que introduce algunos datos en una aplicación cliente y pulsa "return". La aplicación cliente envía un mensaje a una aplicación del servidor, espera una respuesta y luego envía otro mensaje, espera una respuesta, etc.; para un número N de "vueltas". Al final de N turnos la aplicación cliente presenta los resultados de vuelta a usted.

Supongamos que se requieren 10 turnos y que la aplicación del servidor tarda 1ms en procesar el mensaje del cliente y enviar una respuesta. Con una latencia de 1ms se obtiene un tiempo de respuesta de 10 * (1ms + 1ms) o 20ms. Ahora súbete a un avión y viaja a Chicago, el servidor se queda en Boston así que ahora tienes una latencia de digamos 50ms y un tiempo de respuesta de 10 * (50ms + 1ms) o 550ms. Esto es suficiente para ser notorio pero no doloroso. Aumenta el número de vueltas a 100 y ahora tienes un doloroso tiempo de respuesta de 5,5 segundos. Puedes pensar que 100 giros es excesivo pero algunas consultas a bases de datos complejas o aplicaciones que llenan formularios complejos pueden hacer precisamente eso. ¿Sabes cuántos turnos requieren tus aplicaciones?
Hacer un copy_file vía OSL también muestra este comportamiento. OSL enviará un archivo en transacciones de 4K. Cada transacción requiere una respuesta, así que un archivo de 1.000.000 de bytes requerirá 1.000.000 / 4.096 = 245 transacciones o turnos para usar la nomenclatura del párrafo anterior. De nuevo, suponiendo 1ms para procesar la transacción y una latencia de 1ms el archivo copy_file tomará 490ms. Si aumentamos la latencia a 50ms tomará 12.495 segundos. Si aumentamos el archivo a 1.000.000.000 de bytes requerirá 244.141 transacciones; con los tiempos correspondientes de 488.282 segundos para una latencia de 1ms y 12.451.191 segundos o casi 3,5 horas para una latencia de 50ms.

La forma más simple de medir la latencia es con ping.

También puedes usar un programa que escribí que multiplica las conexiones sin necesidad de usar packet_monitor. Ver http://members.cox.net/ndav1/self_published/stcp_tping.doc. El comando stcp_tping requiere que te conectes a un puerto activo en el host remoto. En este caso estoy usando el puerto 23 (telnet) pero cualquier puerto activo funcionará. El número 1 al final del comando indica que se enviará una petición una vez por segundo.