JavaScript (Node) no tiene multi-threading, y desperdicia el hardware que podrías usar.

gistfile1.txt

Las opciones sugeridas para utilizar todo el hardware disponible son:

1. Modulo “cluster”.
2. Usar Web Workers o algun otro modo de comunicacion entre procesos para dividir el trabajo.
3. Usar N procesos en vez de threads.

Ninguna de estas opciones sirve.

Suponiendo que tu hardware tiene N cores, veamos las opciones en detalle:

1. Cluster: basicamente crea un cluster de procesos con los cual te comunicas a traves de TCP un protocolo de alto nivel que no permite ningun tipo de eficiencia (haces el “caro” TCP handshake cada vez), es muchos ordenes de magnitud mas caro que usar threads locales. Ridículamente mas lento, pesado y caro.

2. WebWorkers: parecido al problema anterior, pero peor, ya que el pase de mensajes a los “workers” es serial, es decir no podes mandar _paralelamente_ mensajes con los trabajos a tus workers. Cada mensaje es serializado y despues mandado a los workers (gasto innecesario). Ademas, workers usan un threadpool (libuv) limitado.

3. Procesos en vez de threads: Este es el que la mayoria sugiere y es de hecho, el peor. Supongamos que tenes una tarea muy pesada (CPU bound) que necesitas procesar en cada request, para poder hacerlo necesitas dividir la tarea (en lo posible) en una cantidad de tareas paralelas, si tu app es single thread no tenes forma de dividirla y paralelizar ese calculo con lo cual tu limite va a ser siempre *un solo core*, lo cual es un desperdicio total, las nuevas CPU de Intel van a venir con 18 cores, vas a desperdiciar 17 campeón.
Sumado a todo eso, al tener N procesos corriendo con tu app vas a multiplicar los costos de memoria, disco y archivos abiertos por N, desperdiciando totalmente los recursos de tu hardware.