I'm using the Node.js cluster module in a simple Express application on Windows, aiming to leverage multiple CPU cores for parallel request handling. My goal is to prevent blocking when CPU-intensive tasks are involved. I have a /timer route that simulates a CPU-bound operation using a blocking delay() function. Despite using the cluster module and setting the scheduling policy to round-robin, concurrent requests to the /timer endpoint still seem to block each other. I'm observing that when two requests are made nearly simultaneously, the second request waits for the first to complete (which takes approximately 9 seconds), even though I expect different worker processes to handle them concurrently. Here's the code I'm using:

const express = require("express");
const cluster = require("cluster");
const os = require("os");

const numCPUs = os.cpus().length; // Get the number of CPU cores

cluster.schedulingPolicy = cluster.SCHED_RR;

function delay(duration) {
  const startTime = Date.now();
  while (Date.now() - startTime < duration) {
    // Event loop is blocked
  }
}

// If it's the master process, create workers
if (cluster.isMaster) {
  console.log(`Master process ${process.pid} is running`);

  // Create a worker process for each CPU core
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();

  }

  // Restart worker if it crashes
  cluster.on("exit", (worker) => {
    console.log(`Worker ${worker.process.pid} died. Restarting...`);
    cluster.fork();
  });
} else {
  console.log(`Worker ${process.pid} started`);

  const app = express();

  app.get("/", (req, res) => {
    res.send("Performance Example");
  });

  app.get("/timer", (req, res) => {
    delay(9000);
    res.send(`Processed by worker ${process.pid}`);
  });

  app.listen(3000, () => {
    console.log(`Worker ${process.pid} is listening on port 3000`);
  });
}

What I've Tried: I've explicitly set the cluster.schedulingPolicy to cluster.SCHED_RR in an attempt to ensure that incoming connections are distributed among worker processes using a round-robin algorithm. I'm doing this because I understand that Windows might not default to round-robin scheduling. I've tried setting the environment variable NODE_OPTIONS=--experimental-worker to enable any potentially relevant experimental features. This did not resolve the issue.

I'm expecting the cluster module to distribute the incoming requests to the /timer endpoint across the available worker processes in a round-robin fashion. This means that if two requests arrive at nearly the same time, they should be handled by different worker processes concurrently, preventing the blocking behavior that I'm currently observing.