Linux Server Network Development Model

¿Por qué el rendimiento de Nginx es mucho mejor que el de Apache?

Esto se debe principalmente a que Nginx utiliza la última E /S de red epoll (Linux 2.6 kernel) y kqueue (FreeBSD). Modelo, mientras que Apache utiliza el modelo de selección tradicional. Vi un ejemplo en un blog: supongamos que estás estudiando en una universidad, esperando que lo visite un amigo, y este amigo solo sabe que estás en el Edificio A, pero no sé dónde vives, por lo que haces una cita. Me encontré en la puerta del Edificio A. Si usa el modelo de bloqueo de E /S para resolver este problema, solo puede esperar la llegada de amigos a la puerta del Edificio A. Durante este tiempo no puede hacer nada más, no. Es difícil saber que la eficiencia de este método es baja. Ahora que los tiempos han cambiado, comencé a usar el modelo multiplexado de IO para enfrentar este problema. Le dijo a su amiga que viniera al Edificio A para encontrar a la tía del edificio, déjelo que le diga. Cómo llegar. La tía del edificio aquí desempeña el papel de IO multiplexado.

Explica el modo de trabajo de los modelos select y epoll: La versión de la versión selecta de la tía hace lo siguiente: Por ejemplo, un amigo de la clase A viene, la tía de la versión seleccionada es estúpida, lleva a un amigo a pedirle a una habitación que pregunte quién es un compañero de clase. A, estás esperando un amigo. Si todos los amigos que acuden a un amigo en el departamento de administración del edificio tienen que preguntar sobre los compañeros de clase en todo el edificio, la eficiencia del tratamiento será inevitablemente baja. Poco después, habrá mucha gente en la parte inferior del edificio. La versión de Epoll de la tía es más avanzada, escribió la información del compañero de clase A, como el número de su habitación, luego, cuando venga el amigo de la clase A, solo dígale al amigo que es compañero de clase A en qué habitación, no tiene que traerlo usted mismo. Buscando a alguien en el edificio. La tía de Epoll puede localizar al compañero de clase A sin el poder de soplar. De un vistazo, entiendo la diferencia entre los modelos epoll y selectos.

En el kernel de Linux, el FD_SET utilizado por select es limitado, es decir, el kernel tiene un parámetro __FD_SETSIZE que define el número de manejadores para cada FD_SET, en el código fuente del kernel /usr /include /linux /posix_types .h #undef __FD_SETSIZE # define __FD_SETSIZE 1024 Si desea detectar el estado legible o escribible de 1025 identificadores al mismo tiempo, no es posible seleccionar. La implementación de select en el kernel utiliza el método de sondeo, es decir, cada verificación atravesará los manejadores en todos los FD_SET. Obviamente, cuanto más tiempo de ejecución de la función de selección y el número de manejadores detectados por el FD, más tiempo consumirá.

epoll es una forma de multiplexar IO (I /O Multiplexing), solo para linux2.6 y superior. El modelo epoll admite el límite máximo de FD, que es el número máximo de archivos abiertos. Este número generalmente es mucho mayor que 2048. Por ejemplo, en una máquina con 1 GB de memoria, es de aproximadamente 100.000. Para obtener más información, consulte: cat /proc /sys /Fs /file-max, este número tiene mucho que ver con la memoria del sistema. Otra debilidad fatal de la selección /encuesta tradicional es que cuando tienes una gran colección de sockets, pero debido a la latencia de la red, solo una parte del socket está activa en cualquier momento, pero la selección /encuesta será lineal cada vez que se llame. Escanear todas las colecciones da como resultado una disminución lineal en la eficiencia. Pero epoll no tiene este problema, solo opera en los sockets "activos", esto se debe a que en la implementación del núcleo, epoll se implementa de acuerdo con la función de devolución de llamada en cada fd. Entonces, solo el zócalo activo activará la función de devolución de llamada y otros zócalos de estado inactivo no. En este punto, epoll implementa un pseudo AIO, porque esta vez la fuerza motriz está en os Kernel En algunos puntos de referencia, si todos los sockets están básicamente activos, como un entorno de LAN de alta velocidad, epoll no es más eficiente que seleccionar /sondear. Por el contrario, si usa demasiado epoll_ctl, la eficiencia es ligeramente menor. . Pero una vez que usa conexiones inactivas para simular un entorno WAN, epoll es mucho más eficiente que seleccionar /sondear.

Epoll tiene dos modos de trabajo: Activado por flanco (ET), Activado por nivel (LT) LT (nivel activado) es el modo predeterminado de operación, y es compatible con enchufes de bloque y sin bloque. El kernel le dice si un descriptor de archivo está listo, y luego puede realizar operaciones de E /S en este fd listo. Si no hace nada, el kernel continuará notificándole, por lo que es menos probable que este modo esté programado. La selección /encuesta tradicional es representativa de este modelo. ET (activada por el borde) es un modo de operación de alta velocidad que solo admite tomas sin bloqueo. En este modo, el kernel le dice a través de epoll cuando el descriptor nunca ha estado listo para estar listo. Luego, se supone que sabe que el descriptor de archivos está listo y que no enviará más notificaciones listas para ese descriptor de archivos hasta que haga algo que haga que el descriptor de archivos ya no esté listo (por ejemplo, Un error EWOULDBLOCK se produce cuando se envía, recibe o recibe una solicitud, o cuando se envía y recibe menos de cierta cantidad de datos.