nodejs: ¿Por qué Node.js puede manejar una gran cantidad de conexiones persistentes simultáneas?

Sé que Node.js es bueno para mantener un gran número de conexiones persistentes simultáneas, por ejemplo, una sala de chat para muchas personas.nodejs: ¿Por qué Node.js puede manejar una gran cantidad de conexiones persistentes simultáneas?

Me pregunto cómo se logra esto. Quiero decir, de todos modos, está usando TCP/IP que está encapsulado por el sistema operativo subyacente, ¿por qué puede manejar las conexiones persistentes tan bien que otros no?

¿Qué es lo mágico que tiene?

Fuente

2012-05-12 Jackson Tale

@MartinJames: Creo que hemos dejado los tiempos en que JS era el dominio de los script kiddies. No hay necesidad de comentarios maliciosos del lingüista. – Amadan

@Amadan La pregunta OP está a punto de ser una promoción comercial. No parece "Una pregunta práctica y respondible basada en problemas reales enfrentados", (preguntas frecuentes). Una observación lingüística parecía apropiada. No lo rechacé ni voté para cerrarlo porque existe la posibilidad de que sea una pregunta genuina. –

@MartinJames: No, si creía que una pregunta no pertenece a SO, un puntero a preguntas frecuentes es apropiado, no eso. ¿Habría respondido de la misma manera si la pregunta era sobre [node.cs] (https://github.com/Rduerden/Node.cs), siendo todas las demás cosas iguales? – Amadan

Node.js hace que todas las E/S sean asíncronas. Solo se ejecuta en un solo subproceso, pero realizará otras solicitudes u operaciones mientras espera en E/S.

En contraste, los servidores web clásicos no atenderán a otra solicitud hasta que la anterior esté completa. Por esta razón, Apache ejecuta varios procesos al mismo tiempo; digamos que hay 10 procesos httpd, lo que normalmente significa que se pueden atender 10 solicitudes en cualquier momento (*). Si los procesos tardan más en completarse, usted atenderá menos solicitudes, o tendrá que engendrar más procesos, incluso si el proceso no está haciendo nada, como esperar a que la base de datos muerda y devuelva datos.

Un proceso node.js, frente a una solicitud que irá a la base de datos, deja la base de datos en funcionamiento mientras va a atender otra solicitud.

*) MPM hace que esto no sea del todo cierto, pero lo suficientemente cierto para todos los intentos y propósitos.

Fuente

2012-05-12 11:33:00 Amadan

Tengo mucha curiosidad de que si Node.js está usando IO no bloqueante, ¿por qué otros gigantes como Apache no pueden producir una cosa sin bloqueo? ¿Por qué httpd no se modificará a este tipo de marco? y pueden? –

Seguridad. Apache hace lo que hace bien; aislar las solicitudes de los demás es parte de esto. Sin embargo, siempre que no desee que las solicitudes estén aisladas, Apache no se ocupa de ellas muy bien; aunque Phusion Passenger y FastCGI ayudan. Tenga en cuenta: Apache principalmente sirve páginas estáticas; todo lo demás pasa por CGI o mediante complementos (módulos de Apache). Por lo tanto, optimizar Apache para E/S es como optimizar los gansos para tirar de los carros. (Por otro lado, cuando se habla de Ruby o Python, ambos pueden hacer lo mismo que node.js a través de sus respectivas bibliotecas de sincronización: EventMachine o Twisted.) – Amadan

Bueno, la cosa es que la mayoría de los servidores web (como apache, etc.) funcionan usando el engendramiento de subprocesos, donde introducen un nuevo hilo para cada solicitud HTTP entrante. estos hilos son sincrónicos y bloqueantes en nature =>, lo que significa que ejecutarán el código en el orden en que fue escrito y cualquier cómputo adicional será bloqueado por la E/S actual o la tarea de cálculo. Por ejemplo, si desea escuchar un evento como: el envío de chat por chatter, necesita tener un hilo dedicado por usuario (por usuario es necesario para mantener una conexión constante, existen pocas técnicas de optimización posibles, pero aún puede suponer que los hilos serán por usuario) escuchando este evento y este hilo será bloqueado esperando que ocurra este evento. Por lo tanto, para cualquier enhebrado y bloqueo de secuencias web-server

JavaScript, por otro lado, no bloquea (y es conductor de códigos asincrónicos) por naturaleza => aquí registra una devolución de llamada para un evento y siempre que ocurra alguna función de devolución de llamada será ejecutado. No se bloqueará en ningún punto esperando por este evento.

Puede encontrar más información sobre esto leyendo sobre servidores no bloqueantes o asíncronos.

Fuente

2012-05-12 11:44:44

JavaScript no es asíncrono, node.js es. JavaScript es más bien conductivo para el estilo de codificación asíncrono (o más bien, el estilo de continuación de paso), debido a la ciudadanía de primera clase de las funciones; pero no hay nada particularmente asincrónico en JavaScript. – Amadan

nodejs: ¿Por qué Node.js puede manejar una gran cantidad de conexiones persistentes simultáneas?

Respuesta

Cuestiones relacionadas