Response time optimization in Node.js - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Event Loop Impact on Response Time

In Node.js, which scenario best explains why a long-running synchronous function can increase response time for incoming requests?

A The event loop prioritizes new requests over synchronous functions, so response time is unaffected.

B The function runs in a separate thread, so it does not affect response time.

C Node.js automatically splits synchronous functions into smaller tasks to avoid blocking.

D The event loop is blocked, so new requests must wait until the function finishes.

💡 Hint

Think about how Node.js handles tasks in a single thread.

Node.js uses a single-threaded event loop. If a synchronous function runs for a long time, it blocks the event loop. This means new incoming requests cannot be processed until the function finishes, increasing response time.

❓ component_behavior

intermediate

Effect of Async/Await on Response Time

Consider this Node.js code snippet handling HTTP requests. What is the main benefit of using async/await here for response time optimization?

Node.js

const http = require('http');

http.createServer(async (req, res) => {
  const data = await fetchDataFromDB();
  res.end(data);
}).listen(3000);

A It allows the server to handle other requests while waiting for the database response.

B It makes the database query run faster.

C It blocks the event loop until the database returns data.

D It caches the database response to reduce future response times.

💡 Hint

Think about what async/await does to the event loop.

Using async/await lets Node.js pause the current request handler without blocking the event loop. This allows the server to process other incoming requests while waiting for the database, improving overall response time.

🔧 Debug

advanced

Identifying Cause of Slow Response in Middleware

Given this Express middleware, what is the cause of increased response time?

Node.js

app.use((req, res, next) => {
  const start = Date.now();
  while (Date.now() - start < 100) {
    // busy wait for 100ms
  }
  next();
});

A The middleware calls next() too early, causing race conditions.

B The middleware uses asynchronous code incorrectly, causing delays.

C The busy wait blocks the event loop, delaying all requests.

D The middleware does not call next(), so requests hang indefinitely.

💡 Hint

Consider what happens when the event loop is busy waiting.

The busy wait loop blocks the event loop for 100ms on every request. This prevents Node.js from handling other requests during that time, increasing response time significantly.

📝 Syntax

advanced

Correct Use of setImmediate for Response Time

Which option correctly uses setImmediate to defer a CPU-heavy task without blocking the response?

Node.js

app.get('/heavy', (req, res) => {
  // CPU-heavy task here
  res.end('Done');
});

A

app.get('/heavy', (req, res) => {
  heavyTask();
  setImmediate(() => res.end('Done'));
});

B

app.get('/heavy', (req, res) => {
  setImmediate(() => {
    heavyTask();
  });
  res.end('Done');
});

C

app.get('/heavy', (req, res) => {
  setTimeout(() => {
    heavyTask();
    res.end('Done');
  }, 0);
});

D

app.get('/heavy', (req, res) => {
  res.end('Done');
  heavyTask();
});

💡 Hint

The response should be sent immediately, and the heavy task deferred.

Option B defers the CPU-heavy task using setImmediate, allowing the response to be sent immediately. This prevents blocking the event loop and improves response time.

❓ state_output

expert

Analyzing Response Time with Caching and Async Calls

Consider this Node.js code snippet using a simple cache. What will be the output time difference between the first and second request to /data endpoint?

Node.js

const http = require('http');
let cache = null;

async function fetchData() {
  return new Promise(resolve => setTimeout(() => resolve('data'), 100));
}

http.createServer(async (req, res) => {
  if (req.url === '/data') {
    if (cache) {
      res.end(cache);
    } else {
      const data = await fetchData();
      cache = data;
      res.end(data);
    }
  } else {
    res.end('Not found');
  }
}).listen(3000);

A First request takes about 100ms; second request is almost instant due to cache.

B Both requests take about 100ms because fetchData is called every time.

C First request is instant; second request takes 100ms because of cache delay.

D Both requests are instant because cache is prefilled.

💡 Hint

Think about when fetchData is called and when cache is used.

The first request calls fetchData, which takes 100ms. The result is stored in cache. The second request uses the cached data and responds immediately, reducing response time.

Practice

1. Which of the following is a common technique to improve response time in a Node.js application?

easy

A. Writing all code synchronously to keep it simple

B. Using only synchronous file system calls

C. Increasing the number of console.log statements

D. Using asynchronous functions to avoid blocking the event loop

Solution

1. Step 1: Understand Node.js event loop behavior

   Node.js uses an event loop that runs best when tasks are asynchronous, avoiding blocking operations.

2. Step 2: Identify the impact of async functions

   Using asynchronous functions allows Node.js to handle other requests while waiting, improving response time.

3. Final Answer:

   Using asynchronous functions to avoid blocking the event loop -> Option D

4. Quick Check:

   Async = faster response [OK]

Hint: Async code keeps Node.js responsive and fast [OK]

Common Mistakes:

• Thinking synchronous code is faster
• Ignoring event loop blocking
• Believing console.log improves speed

2. Which syntax correctly uses caching middleware in an Express.js app to improve response time?

easy

A. app.use(cacheMiddleware);

B. app.cacheMiddleware();

C. cacheMiddleware(app);

D. app.cache.useMiddleware();

Solution

1. Step 1: Recall Express middleware usage

   Middleware is added using app.use(middlewareFunction) to apply it to requests.

2. Step 2: Match correct syntax

   Only app.use(cacheMiddleware); correctly applies the middleware function.

3. Final Answer:

   app.use(cacheMiddleware); -> Option A

4. Quick Check:

   Middleware added with app.use() [OK]

Hint: Use app.use() to add middleware in Express [OK]

Common Mistakes:

• Calling middleware as a method on app
• Passing app as argument to middleware
• Using incorrect method names

3. What will be the output response time behavior of this Node.js code snippet?

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

app.get('/data', async (req, res) => {
  const data = await fetchDataFromDb();
  res.send(data);
});

function fetchDataFromDb() {
  return new Promise(resolve => setTimeout(() => resolve('DB Data'), 2000));
}

app.listen(3000);

medium

A. Responds after 2 seconds with 'DB Data'

B. Responds immediately with 'DB Data'

C. Responds immediately with an empty response

D. Throws an error due to missing callback

Solution

1. Step 1: Analyze fetchDataFromDb function

   This function returns a promise that resolves after 2 seconds with 'DB Data'.

2. Step 2: Understand async/await in route handler

   The route waits for fetchDataFromDb to finish before sending response, causing 2 seconds delay.

3. Final Answer:

   Responds after 2 seconds with 'DB Data' -> Option A

4. Quick Check:

   Await delays response by 2 seconds [OK]

Hint: Await pauses response until promise resolves [OK]

Common Mistakes:

• Assuming immediate response despite await
• Confusing async with synchronous code
• Expecting error without callback in async

4. Identify the bug in this Node.js code that aims to optimize response time using caching:

const cache = {};
app.get('/user/:id', (req, res) => {
  if (cache[req.params.id]) {
    res.send(cache[req.params.id]);
    return;
  }
  const userData = getUserFromDb(req.params.id);
  cache[req.params.id] = userData;
  res.send(userData);
});

medium

A. Cache is cleared after every request

B. res.send is called twice causing error

C. getUserFromDb is asynchronous but used synchronously

D. Cache keys are not strings

Solution

1. Step 1: Check res.send calls in both branches

   If cache hit, res.send is called, but code continues and calls res.send again after fetching data.

2. Step 2: Understand Express response behavior

   Calling res.send twice causes an error because response is already sent.

3. Final Answer:

   res.send is called twice causing error -> Option B

4. Quick Check:

   Only one res.send per request allowed [OK]

Hint: Return after sending cached response to avoid double send [OK]

Common Mistakes:

• Ignoring multiple res.send calls
• Assuming synchronous DB call is fine
• Not returning after cache hit

5. You want to optimize response time by streaming a large file in Node.js instead of loading it fully into memory. Which code snippet correctly implements this using Express?

hard

A. app.get('/file', (req, res) => { const fs = require('fs'); res.sendFile(fs.readFileSync('large.txt')); });

B. app.get('/file', (req, res) => { const data = fs.readFileSync('large.txt'); res.send(data); });

C. app.get('/file', (req, res) => { const fs = require('fs'); const stream = fs.createReadStream('large.txt'); stream.pipe(res); });

D. app.get('/file', (req, res) => { const data = fs.readFile('large.txt', (err, data) => { res.send(data); }); });

Solution

1. Step 1: Understand streaming vs full read

   Streaming sends file data in chunks, reducing memory use and improving response time for large files.

2. Step 2: Identify correct streaming code

   Using fs.createReadStream and piping to res streams data efficiently; other options load full file or use callbacks.

3. Final Answer:

   app.get('/file', (req, res) => { const fs = require('fs'); const stream = fs.createReadStream('large.txt'); stream.pipe(res); }); -> Option C

4. Quick Check:

   Stream large files with createReadStream + pipe [OK]

Hint: Use createReadStream and pipe to stream files [OK]

Common Mistakes:

• Using readFileSync blocks event loop
• Using readFile loads entire file before response
• Assuming sendFile streams automatically