Cuando ejecuta Apache Bench en el mismo servidor que el sitio web, como:
ab -n 1000 -c 10 localhost:8080/
Lo más probable es que no obtenga resultados precisos en comparación con los usuarios que acceden al servidor desde varias ubicaciones.
Estoy tratando de entender cómo o más bien por qué esto afectará el rendimiento en el mundo real, ya que un usuario en China tendrá diferentes problemas de latencia en comparación con alguien en el mismo estado/país.
Digamos que mi servidor web tiene un límite máximo de subprocesos de 100.
¿Alguien puede explicar en detalle cómo la latencia del usuario final puede afectar o afectará el rendimiento del servidor?
Supongo aquí que cada solicitud se calculará por igual en, digamos, 10 ms.
Lo que no entiendo es cómo los factores externos pueden afectar el rendimiento general del servidor, específicamente las conexiones a Internet (ubicación o incluso un dispositivo como el móvil) y los protocolos de enlace http/tcp, etc.
Respuesta1
En general, la latencia del usuario final no afecta el rendimiento del servidor. La principal diferencia será que con una mayor latencia del usuario final, su servidor tendrá más conexiones a la vez porque cada conexión tarda un poco más en completarse. Pero el servidor sigue haciendo aproximadamente la misma cantidad de trabajo para cada conexión. Mientras no alcances las limitaciones del servidor, principalmente la memoria, no importa.
El servidor no comenzará a realizar ningún trabajo pesado para una conexión hasta que tenga la solicitud completa. Entonces, si lleva más tiempo configurar la conexión y recibir la solicitud, eso solo significará que el servidor esperará un poco más, mientras básicamente no hace nada, antes de realizar el procesamiento real.
Normalmente, el servidor procesa la solicitud y pone en cola la respuesta de una sola vez. La latencia del cliente y de la red puede significar que se necesita un poco más de tiempo para vaciar esa cola. Pero la parte del servidor que maneja esto está muy optimizada y la lógica para la página u objeto en particular ya se ha ejecutado hasta el final generando la respuesta. De nuevo, normalmente no hay ningún efecto significativo en el rendimiento del servidor.
Sin embargo, la experiencia del cliente puede ser mucho peor. Esto es especialmente cierto si el servicio tiene muchos casos en los que el cliente tiene que obtener información del servidor y luego volver a conectarse para obtener más información. Por ejemplo, si una página web le dice al cliente que cargue un montón de fotogramas y luego esos fotogramas le dicen al cliente que cargue un montón de imágenes, habrá muchas operaciones de "ida y vuelta" (cada una aumentada por la latencia de la red) antes de que el cliente cargue un montón de imágenes. El cliente ve un resultado. Pero el servidor hace la misma cantidad de trabajo.
Respuesta2
En realidad, eso no será un problema a menos que tenga un procesador multi-multi que funcione en tiempo real (digamos, una cantidad de 1K Cpu), una súper computadora con mucha memoria...
En un sistema multiproceso, todos los procesos tienen una ventana de tiempo que se llama Quantum Size. Los sistemas operativos con capacidades multiproceso, como es el caso aproximadamente desde los años 80 hasta los 90 hasta la actualidad, oscilan entre procesos en ejecución, dándole a cada uno de ellos ese tamaño cuántico. Esta ventana de tiempo es de alrededor de 20 milisegundos en nuestros sistemas operativos modernos y esa conmutación se realiza muy rápidamente con una sobrecarga de conmutación muy baja. Digamos, si tenemos una CPU y dos procesos se cambian entre sí, en 1 segundo, lo que equivale a 1000 milisegundos, podemos ejecutarlos durante 900-950-980 (tal vez) milisegundos (la diferencia desapareció para el cambio de proceso). ). De todos modos, como dije, este cambio se realiza muy rápido e imagina 50 procesos ejecutándose, vemos que todos los procesos se ejecutan simultáneamente. En realidad no lo son y eso es multiprocesamiento, conceptos básicos de la programación de procesos...
Cuando tenemos subprocesos múltiples en procesos, el sistema operativo programa el proceso primero y le da un cuanto, luego programa los subprocesos en ese proceso. Y en ese cuanto, los hilos también se programan. Cuando finaliza todo el cuanto, el sistema operativo programa otro proceso (o el mismo según el algoritmo de programación) y también se programan los subprocesos de ese nuevo proceso.
Hay dos niveles de entorno de ejecución para subprocesos. Uno es el nivel de usuario, dos es el nivel de kernel. El que mencioné anteriormente es el nivel de usuario. Programación de procesos, programación de subprocesos en ese tamaño cuántico. Pero, cuando baja al nivel del kernel, el programador puede programar diferentes subprocesos de diferentes procesos. El cuanto se aplica a los subprocesos directamente en el nivel del núcleo...
Después de hablar de todo eso, comencemos a comprender cómo la latencia de una conexión final puede afectar el rendimiento del servidor:
Sus subprocesos deben estar en el nivel de kernel si desea el máximo rendimiento, y sé que los subprocesos de Apache no están en modo kernel. Apache en sí está en modo de usuario, es una aplicación de usuario final y sus subprocesos se ejecutan en modo de nivel de usuario. Por lo tanto, no obtendrá un rendimiento del 100 % de ese servidor de ninguna manera... Digamos que los subprocesos se ejecutan en modo kernel y tiene dos CPU. Un hilo para la primera CPU, un hilo para la segunda. Ahora realmente se están ejecutando dos subprocesos simultáneamente. Un hilo de trabajo web es en realidad un I/O Boundedhilo desde el punto de vista del sistema operativo y cuando solicita algún archivo, se bloqueará hasta que el archivo esté listo. El programador programará la ejecución de otro subproceso de trabajo. Cuando "ese" archivo esté listo, el hilo bloqueado pasará a la cola de listos y se programará nuevamente. Así que muy bien... ¿Qué pasa si tienes 100 hilos de trabajo? Esta pregunta trae otra pregunta: ¿Cuándo se crea un hilo de trabajo?
Hablando de aplicaciones de servidor web, se crea un subproceso de trabajo cuando low-level IP connection is made. Entonces, sus dos subprocesos reales ya se están ejecutando, una nueva conexión establecida por hardware (tienen sus propias PU e interrumpen el sistema principal para la transferencia de información de datos), apareció un nuevo subproceso de trabajo, se envió a la cola lista para su programación. ...
Volver al tema principal, cómo un factor externo afecta el rendimiento del sistema. Se trata de limitaciones del sistema. El número de subprocesos afecta el rendimiento si el sistema tiene suficiente unidad de proceso para manejarlos o no. Matemáticas básicas, dos procesadores solo procesan dos subprocesos al mismo tiempo... El ancho incorrecto de la conexión de red afecta el rendimiento en función de "cuántas conexiones puede aceptar". Digamos que los datos de una conexión son de 10 bytes y el ancho de banda es de 100 bytes por segundo, puede tener 10 conexiones por segundo...
Escalarlos depende de usted. Debe recordar solo una cosa: su recurso total de CPU ya está procesando los subprocesos que ya están en la cola listos... Entonces, cuando aparece un nuevo subproceso, simplemente no empeora las cosas para los subprocesos actuales.
El rendimiento puede ser un problema cuando la aplicación del servidor. primeras salidas. Rápidamente alcanzará el límite superior. Es una especie de aceleración de un coche. Acelerará primero y alcanzará la velocidad máxima después de un tiempo. Puedes ir a máxima velocidad hasta que te quedes sin gasolina o quitar el pie del acelerador.