Tengo un servidor web con una conexión actual de 100Mbit y mi proveedor ofrece una actualización a 1Gbit. Entiendo que esto se refiere al rendimiento, pero cuanto más grandes son los paquetes, más rápido también se pueden transmitir, por lo que esperaría una ligera disminución en el tiempo de respuesta (por ejemplo, ping). ¿Alguien alguna vez comparó esto?
Ejemplo (servidor de 100mbit a 100mbit) con carga de 30 bytes:
> ping server -i0.05 -c200 -s30
[...]
200 packets transmitted, 200 received, 0% packet loss, time 9948ms
rtt min/avg/max/mdev = 0.093/0.164/0.960/0.093 ms
Ejemplo (servidor de 100mbit a 100mbit) con una carga de 300 bytes (que está por debajo de MTU):
> ping server -i0.05 -c200 -s300
[...]
200 packets transmitted, 200 received, 0% packet loss, time 10037ms
rtt min/avg/max/mdev = 0.235/0.395/0.841/0.078 ms
Entonces de 30 a 300 el promedio. la latencia aumenta de 0.164 a 0.395: esperaría que este sea un aumento más lento para una conexión de 1 gibt a 1 gbit. Incluso esperaría que 100mbit a 1gbit sea más rápido, si la conexión es a través de un conmutador que primero espera hasta que reciba el paquete completo.
Actualización: ¡ Lea los comentarios a las respuestas cuidadosamente! La conexión no está saturada, y no creo que este aumento de velocidad sea importante para los humanos para una solicitud, pero se trata de muchas solicitudes que se suman (Redis, Base de datos, etc.).
Respecto a la respuesta de @LatinSuD :
> ping server -i0.05 -c200 -s1400
200 packets transmitted, 200 received, 0% packet loss, time 9958ms
rtt min/avg/max/mdev = 0.662/0.866/1.557/0.110 ms
fuente
Respuestas:
La única forma en que la latencia se reduciría notablemente es si el enlace actual de 100Mbit está saturado. Si no está saturado, es probable que no note ningún cambio.
Además, su suposición de que el enlace de 1 Gbit podrá admitir paquetes más grandes es incorrecta. El tamaño máximo de paquete está determinado por la MTU de los diversos dispositivos a lo largo de la ruta que toma el paquete, comenzando con la NIC en su servidor, hasta la MTU de la computadora de su cliente. En aplicaciones LAN internas (cuando tiene control sobre todos los dispositivos a lo largo de la ruta), a veces es posible aumentar la MTU, pero en esta situación, está atascado con la MTU predeterminada de 1500. Si envía paquetes más grandes que eso, terminarán fragmentándose, disminuyendo así el rendimiento.
fuente
SÍ gbit tiene una latencia más baja, ya que:
PERO la mejora solo es apreciable si los paquetes tienen un cierto tamaño:
Entonces, si tiene una aplicación que es muy sensible a la latencia (4 ms frente a 0,8 ms, ida y vuelta por 20 kb) y requiere que se transfieran paquetes más grandes, entonces cambiar de 100mbit a gbit puede proporcionarle una reducción de latencia, aunque use mucho menos que los 100mbit / s en promedio (= el enlace no está saturado permanentemente).
Servidor (100mbit) -> Switch (gbit) -> Servidor (100mbit):
Servidor (gbit) -> Switch (gbit) -> Servidor (gbit):
= en promedio en varios servidores 80% de reducción de latencia para ping de 20 kb
(Si solo uno de los enlaces es gbit, aún tendrá una reducción de latencia del 5% para ping de 20 kb).
fuente
Creo que tiene una idea errónea fundamental sobre la latencia del ancho de banda y la "velocidad". La velocidad es una función del ancho de banda y la latencia. Por ejemplo, considere un envío de datos en DVD enviados en todo el país que demore 3 días en llegar. Compare eso con el envío de datos a través de Internet. Internet tiene una conexión de latencia mucho más baja, pero para que coincida con la "velocidad" de la conexión al envío, debería haber recibido a 9.6MB por segundo ( ejemplo de referencia de esta fuente ).
En su caso, la actualización a un mayor ancho de banda le permitiría atender a más usuarios concurrentes, pero no mejoraría la latencia de ningún usuario individual.
fuente
Estás mirando el mundo a través de un agujero de alfiler. Una prueba válida de las diferencias de latencia a diferentes velocidades sería entre dos NIC idénticas conectadas con un cable de conexión cruzada. Establezca las velocidades de emparejamiento de NIC de 10mb, 100mb y 1000mb. Esto mostrará que prácticamente no hay diferencia en la latencia a las diferentes velocidades. Todos los paquetes viajan a la misma velocidad de cable, independientemente del ancho de banda máximo utilizado. Una vez que agrega interruptores con almacenar y reenviar el almacenamiento en caché, todo cambia. La prueba de latencia a través de un conmutador debe realizarse con solo dos conexiones al conmutador. Cualquier otro tráfico puede afectar la latencia de su prueba. Incluso entonces, el conmutador puede transferir registros, ajustar los contadores de tipo de paquete, actualizar el reloj interno, etc. Todo puede afectar la latencia.
Sí, cambiar de 100mb a 1gb podría ser más rápido (menor latencia) debido a cambios de hardware, diferentes NIC, diferentes interruptores, diferentes controladores. He visto cambios más grandes en la latencia de ping de las diferencias de controladores que cualquier otro cambio; ancho de banda, conmutadores, NIC de descarga, etc.
El cambio sería el próximo cambio más importante con un corte significativamente más rápido que almacenar y reenviar para pruebas de transmisión única. Sin embargo, un interruptor de almacenamiento y avance bien diseñado puede adelantar al interruptor de corte en el rendimiento general bajo una carga alta. En los primeros días de gigabit, he visto conmutadores de plano posterior de alto rendimiento de 10 MB con una latencia más baja que los conmutadores gigabit baratos.
Las pruebas de ping son prácticamente irrelevantes para el análisis de rendimiento cuando se utiliza Internet. Son pruebas rápidas para tener una idea aproximada de lo que sucede en el transporte en el momento de la prueba. Las pruebas de rendimiento de producción son mucho más complicadas que un simple ping. Los interruptores de alto rendimiento son computadoras y bajo alta carga se comportan de manera diferente: cambio en la latencia.
Tener una NIC más lenta, o una NIC configurada a una velocidad más lenta, en realidad podría ayudar a un servidor con ráfagas concurrentes al limitar la entrada al servidor utilizando la caché de conmutadores. Una sola retransmisión puede negar cualquier disminución en la latencia. Por lo general, los niveles de tráfico de carga media a alta son importantes, no pruebas de ping individuales. por ejemplo, el viejo y lento Sun Ultrasparc (mayor latencia para un solo ping) supera al nuevo escritorio gigabit barato que se utiliza como servidor de desarrollo cuando tiene una carga de ancho de banda inferior al 70%. El escritorio tiene una NIC gb más rápida, una conexión gb-gb más rápida, una memoria más rápida, más memoria, un disco más rápido y un procesador más rápido, pero no funciona tan bien como el hardware / software de clase de servidor sintonizado. Esto no quiere decir que un servidor sintonizado actual que ejecuta gb-gb no sea más rápido que el hardware antiguo, incluso puede manejar cargas de mayor rendimiento. Simplemente hay más complejidad en la cuestión de "
Averigüe si su proveedor está utilizando diferentes conmutadores para las conexiones de 100 mb frente a 1 gb. Si usan el mismo panel posterior del interruptor, solo pagaría el aumento si los niveles de tráfico superaran el ancho de banda más bajo. De lo contrario, es posible que en poco tiempo muchos otros usuarios se cambien al gigabit y los pocos usuarios que quedan en el antiguo conmutador ahora tengan un mayor rendimiento: menor latencia, durante altas cargas en el conmutador (carga general del conmutador, no solo a sus servidores )
Ejemplo de manzanas y naranjas: el ISP local proporcionó un nuevo conmutador para servicios integrados, DSL y teléfono. Inicialmente, los usuarios vieron un aumento en el rendimiento. El sistema estaba sobrevendido. Ahora los usuarios que permanecen en el conmutador anterior tienen un rendimiento consistente más alto. Durante la noche, los usuarios del nuevo sistema son más rápidos. Por la noche, bajo una gran carga, los antiguos clientes de conmutadores superan claramente al nuevo sistema sobrecargado.
Una latencia más baja no siempre se correlaciona con una entrega más rápida. Usted menciona MySQl en las 20 solicitudes para publicar una sola página. Ese tráfico no debe estar en la misma NIC que la página solicita. Mover todo el tráfico interno a una red interna reducirá las colisiones y el recuento total de paquetes en la NIC saliente y proporcionará mayores ganancias que la ganancia de latencia de 0.04 ms de un solo paquete. Reduzca el número de solicitudes por página para reducir la latencia de carga de la página. Comprima las páginas, html, css, javascript, imágenes para disminuir los tiempos de carga de la página. Estos tres cambios darán mayores ganancias generales continuas que pagar por el ancho de banda que no se usa para obtener una reducción de latencia de 0.04 ms. El ping debe ejecutarse las 24 horas y promediarse para ver el verdadero cambio de latencia. Los conmutadores inteligentes ahora hacen una aceleración adaptativa de tipo RTSP con pequeños aumentos iniciales de ancho de banda y grandes transferencias aceleradas. Dependiendo de los tamaños de sus páginas (gráficos, html / css / javascript grandes), puede ver latencias de conexión iniciales / ancho de banda mucho más bajo / más alto que una página grande o transferencias de página completa. Si parte de su página está transmitiendo, puede ver un rendimiento drásticamente diferente entre la página y la transmisión.
fuente
Supongamos paquetes de 300 bytes (si lo usa,
-s 300en realidad sería más grande debido a los encabezados).0.024 ms es aproximadamente el tiempo real requerido para enviar la trama (sin contar el tiempo de acceso medio ni los encabezados).
En una secuencia de ping-pong, tomaría el doble de tiempo (0.048 ms), más el tiempo para que el sistema operativo procese la consulta.
Eso significa para mí que su latencia es causada por un 90% de varios factores generales. No estoy seguro si verá mucha diferencia con Gb. Probablemente, una diferencia de menos de 1 ms no se notará en un servidor web.
De todos modos, ¿podrías probar con un paquete realmente grande como 1400 byte?
fuente
Esto depende del tipo de interruptor al que se está conectando. En algunos proveedores (como Crisco ... me refiero a Cisco), los paquetes ICMP regresarán a la CPU ( mordaza ).
Puede encontrar una mejor prueba sería realizar una prueba de host a host utilizando un enlace de 100Mbps y 1Gbps (es decir, no una prueba de host a switch o de host a enrutador).
Al final del día, la latencia se reducirá a la velocidad de reenvío en el conmutador y los detalles de la arquitectura del conmutador (donde se colocan los ASIC en el tablero, cómo se maneja el bloqueo entre las tarjetas de línea, etc.). Buena suerte con tus pruebas.
fuente