Por qué Node.js es mas escalable que IIS?

[matias....@gmail.com]

Hola, como estan?

Soy nuevo en Node.js, vengo trabajando hace mucho con .NET, estuve leyendo mucho y todavia no termino de entender porque Node.js es mucho mas "rapido" y escalable que IIS.

He leido por ahi que como Node.js corre en un unico thread (al menos el javascript) no tiene el costo de levantar y bajar threads pero IIS en teoria resuelve eso con el thread pool. Por otra parte, segun entiendo el JavaScript corre en un unico thread, pero por debajo hay algo manejando multiples threads...

Bueno, queria tirar la duda a ver si les interesa discutirlo o si tienen algun articulo para recomendar!

Gracias!

[Gustavo Machado]

Hola Matias,

Para resumirlo en dos lineas, lo que node.js hace mejor que IIS es que puede mantener un gran numero de conexiones abiertas (imaginate algo del estilo long-polling), y aun así poder seguir aceptando y procesando requests al mismo tiempo. En IIS una vez que un thread se le asigna a un request, ese thread no se usa hasta que el request termina. Si con IIS con .NET haces un Thread.Sleep(2000), por 2 segundos ese thread no lo utiliza nadie (pensa en IO, network, disk, etc).

Espero que se entienda!

Gustavo Machado

mach...@gmail.com

http://machadogj.com

--
Has recibido este mensaje porque estás suscrito al grupo "NodeJS ES" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a nodejs-es+...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

[Angel Java Lopez]

Ver tambien

http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/

algo viejo, pero aun relevante (ahora Node usa libuv, por ejemplo)

Lo que dice de Apache, se podria aplicar a IIS. Yo revisaria algunas frases, pero la idea es:

- Con un solo thread, puede atender, digamos 100, 200 o mas request simultaneos (no free lunch igual, hay seguramente otros recursos que se ocupan, como conexiones/consultas a la base de datos)

En cambio, en IIS o Apache, mas orientados a un pool de threads, se lanzan, digamos 20 threads, cada uno atiende un request, pero si estan todos ocupados, los demas request quedan en cola, hasta que alguno de los 20 threads atendedores se desocupe.

Algo derivado, no tanto relacionado con la escalabilidad, pero bueno para nosotros: no tener que preocuparnos de la concurrencia (por ej. tocar una lista desde dos threads distintos al "mismo tiempo") en JavaScript. Cada vez que hacemos lista.add(...) solo el thread de JavaScript se esta ejecutando. Eso simplifica muchos algoritmos.

Angel "Java" Lopez

@ajlopez

2013/12/16 Gustavo Machado <mach...@gmail.com>

[Paulo Antonio McNally Zambrana]

Hola.

.NET usa netframework, es un sin numero gigantesco de cosas.

NodeJS usa muy poco, https://github.com/joyent/node/tree/master/deps

Entonces consume mucho menos recursos.

NodeJS puede trabajar con cluster, así que lo de los thread no es problema.

Saludos

[Gustavo Machado]

Creo que "node.js es mucho mas rapido y escalable" se refiere a que hace un uso mas eficiente de las conexiones, en vez de tener un thread por conexion, tiene una variable en memoria por conexion. Esto le permite a node.js tener cientos de miles de conexiones abiertas en simultaneo (cosa que con threads no se puede, habria que usar el thread pool que comentas, y encolar los requests). Entonces en condiciones de muy alta concurrencia, node.js puede llegar a procesar muchos mas requests por segundo que .NET.

.NET encola requests, y asigna threads a requests.

Node.js encola operaciones de I/O y asigna requests a variables en memoria.

Espero que aclare algo!

Gustavo Machado

mach...@gmail.com

http://machadogj.com

[Angel Java Lopez]

.NET tienen un approach similar a Java clasico web. Asi, que este articulo supongo que tambien aporta algo a la pregunta inicial

http://strongloop.com/strongblog/node-js-is-faster-than-java/

El gran tema es la IO async (con threads en libuv, pero con soporte del sistema operativo por abajo para no terminar bloqueando tanto thread; igual, que recuerde, en Windows libuv tiene async/io para sockets pero no para files, pero escribo de memoria, tendria que buscar la referencia).

A la larga: no free lunch, siempre algun recurso termina siendo el "bottleneck". Pero al menos, con Node.js, la atencion de los request entrantes es mayor en cantidad simultanea (jeje... cada vez tuerzo mas el castellano ;-) 

Nos leemos!

Angel "Java" Lopez

@ajlopez

[Darío Terrés Cayuelas]

Aunque es un post viejo y abogo por la gestión por eventos de NodeJS, parece que en IIS+.NET han intentado paliar la situación con las llamadas asíncronas liberando al thread para atender otras peticiones hasta que la operación asíncrona de E/S devuelve.
Una solución a la saturación de la piscina de hilos, obviamente consume más recursos que NodeJS, pero da bastante más escalabilidad a IIS.

https://www.asp.net/mvc/overview/performance/using-asynchronous-methods-in-aspnet-mvc-4