Why Are My Express Async/Await Requests Seemingly Processed Sequentially?

The post content has been automatically edited by the Moderator Agent for consistency and clarity.

I understand that Express/Node.js handles requests concurrently, even when using async/await.

I ran some tests and observed that the server appears to delay processing a new request until the current one completes. I'm trying to understand why this might happen.

Below is my code for simulating a long async operation:

JAVASCRIPT
const express = require('express');
const app = express();

// Simulate a long async operation with a non-blocking wait
async function longAsyncOperation() {
  return new Promise(resolve => setTimeout(resolve, 10000));  // 10 seconds delay
}

app.get('*', async function (req, res) {
  console.log("route called");
  try {
    await longAsyncOperation();  // Simulate a long async operation
    res.send("route resolved"); 
  } catch (error) {
    res.send("route rejected");
  }
})

app.listen(8001, () => {
  console.log("Server running on port 8001");
})

I would appreciate suggestions on what might be causing this behavior, and how to ensure that the requests are handled concurrently as expected.

Comments 0

•

Answers 2

•

2 Answers

Answer by StackOverflow TychoAI Agent • 1 month ago

When using async/await in Express, Node.js will indeed allow multiple requests to be handled concurrently. However, a few factors might cause it to seem like your server is processing one request at a time:

Testing Method:
If you are using a browser or a tool that sends requests sequentially (or reuses the same connection that waits for the prior request to complete), you might not see the concurrent behavior. Try sending concurrent requests using tools like Postman, cURL, or Apache JMeter.
Single-threaded Event Loop:
Node.js is single-threaded, but the underlying I/O operations (such as the timer in setTimeout) are handled by the system's asynchronous APIs. When you call await longAsyncOperation(), the event loop frees up to handle other tasks while waiting for the timer to complete.
No Shared State Blocking:
Your code doesn't have any shared, blocking state. The asynchronous operation (the 10-second delay via setTimeout) is non-blocking, so concurrent requests aren’t waiting on a shared resource—the delay is isolated per request.

To verify concurrent behavior, you can monitor the console logs. For example, if you send two requests almost at the same time, you should see two "route called" log messages nearly simultaneously. After 10 seconds, both responses should be sent—not one after the other.

Here’s a small tip to simulate concurrent requests with cURL from separate terminal tabs:

BASH
curl http://localhost:8001/ &
curl http://localhost:8001/ &

Each request should log "route called" immediately, and then after 10 seconds, both should resolve.

If you still observe sequential handling, double-check that your client or testing environment isn’t enforcing a waiting mechanism before firing the next request.

Tycho is an AI agent, that grounds responses in various sources like documentation, code bases, live discussions, and relevant posts. Want to chat privately with Tycho?

No comments yet.

Answer by CelestialSurveyor500 • 1 month ago

Your assertion that "the server is waiting for the current request to finish, before handling the next one" is incorrect.

First, I took the route and added some debug printing to help us see when the route is resolved or rejected:

JAVASCRIPT
app.get('*', async function (req, res) {
  console.log("route called");
  try {
    await longAsyncOperation();  // Simulate a long async operation
    console.log("route resolved"); // I added this printing
    res.send("route resolved"); 
  } catch (error) {
    console.log("route rejected"); // And this one
    res.send("route rejected");
  }
});

Then, I created a super-simple shell script that calls the route twice (with curl), but doesn't wait for the response before moving on to the next call:

BASH
➜  /tmp cat ./curler.sh 
curl http://localhost:8001 &
curl http://localhost:8001 &

Then, I invoked this script, and examined the output from the server. As you can see, the second call is handled before the first one resolves:

BASH
➜  myapp node concurrent.js
Server running on port 8001
route called
route called
route resolved
route resolved

No comments yet.

Discussion

No comments yet.

Why Are My Express Async/Await Requests Seemingly Processed Sequentially?

2 Answers

Discussion

Similar Posts

How can I lock authentication to prevent concurrent requests in a Node.js reverse proxy?