DEV Community: tawseef nabi

[Boost]

tawseef nabi — Mon, 06 Oct 2025 12:29:33 +0000

Sagar

Sep 14 '25

Level Up Your Sprints: How I'm Using AI to Plan Like a Boss

#discuss #webdev #ai #productivity

Comments

2 min read

Clustering in Node.JS

tawseef nabi — Tue, 16 Aug 2022 14:28:43 +0000

An instance of Node.js runs in a single thread which means that on a multi-core system (which most computers are these days), not all cores will be utilized by the app. To take advantage of the other available cores, you can launch a cluster of Node.js processes and distribute the load between them.

Having multiple threads to handle requests improves the throughput (requests/second) of your server as several clients can be served concurrently. We'll see how to create child processes with the Node.js cluster module and then later, we'll take a look at how to manage clustering with the PM2 Process Manager.
With multiple processes, if one process is busy with a relatively CPU-intensive operation, other processes can take up the other requests coming in, utilizing the other CPUs/cores available. This is the power of the cluster module where workers share the load and the app does not come to a stop due to high load.

The master process can distribute the load to the child process in two ways. The first (and default) is a round-robin fashion. The second way is the master process listens to a socket and sends the work to interested workers. The workers then process the incoming requests.

Building a simple Express server without clustering:

We will start by creating a simple Express server. This server will do a relatively heavy computational task which will deliberately block the event loop. Our first example will be without any clustering.

To get Express set up in a new project we can run the following on the CLI:

mkdir nodejs-cluster-module
cd nodejs-cluster-module/
npm init -y
npm install --save express

Then, we will create a file called no-cluster.js on the root of the project like below:

The contents of the no-cluster.js file will be as follows:

const express = require("express");
const app = express();
const port = 3000;
console.log(`Worker ${process.pid} started`);
app.get("/", (req, res) => {
  res.send("Hello World!");
});

app.get("/api/:n", function (req, res) {
  console.time('no-cluster')
  let n = parseInt(req.params.n);
  let count = 0;

  if (n > 5000000000) n = 5000000000;

  for (let i = 0; i <= n; i++) {
    count += i;
  }
  console.timeEnd('no-cluster')
  console.log("Final count is ", count)
  res.send(`Final count is ${count}`);
});

app.listen(port, () => {
  console.log(`App listening on port ${port}`);
});

the app contains two routes —

a root route that returns the string "Hello World"
another route that takes a route parameter n and adds numbers up to n to a variable count before returning a string containing the final count.
The operation is an 0(n) operation so it offers us easy way to simulate long-running operations on the server — if we feed it a large enough value for n. We cap n off at 5,000,000,000 — let's spare our computer from having to run so many operations.

If you run the app with node app.js and pass it a decently small value for n (e.g. http://localhost:3000/api/50), it will execute quickly and return a response almost immediately. The root route (http://localhost:3000) also returns a response quickly.
we can see response time below

if we increase the value of n, we can see API response takes time. On increasing the value of n, the problem with single thread is clearly visible
e.g if n=5,000,000,000, the App will take few seconds to complete the response

As seen above, the API took 5.179s for n=50000000000 to finish as per our profiling added with console.time and console.timeEnd calls.

Adding Node.js clustering to an Express server

Now, let's use the cluster module in the app to spawn some child processes and see how that improves things.

const express = require("express");
const port = 3000;
const cluster = require("cluster");
const totalCPUs = require("os").cpus().length;

if (cluster.isMaster) {
  console.log(`Number of CPUs is ${totalCPUs}`);
  console.log(`Master ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < totalCPUs; i++) {
    cluster.fork();
  }

  cluster.on("exit", (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
    console.log("Let's fork another worker!");
    cluster.fork();
  });
} else {
  const app = express();
  console.log(`Worker ${process.pid} started`);

  app.get("/", (req, res) => {
    res.send("Hello World!");
  });

  app.get("/api/:n", function (req, res) {
    console.time("cluster")
    let n = parseInt(req.params.n);
    let count = 0;

    if (n > 5000000000) n = 5000000000;

    for (let i = 0; i <= n; i++) {
      count += i;
    }
    console.timeEnd("cluster")
    console.log("Final count is ", count)
    res.send(`Final count is ${count}`);
  });

  app.listen(port, () => {
    console.log(`App listening on port ${port}`);
  });
}

The app does the same thing as before, but this time, we are spawning up several child processes that will all share port 3000 and that will be able to handle requests sent to this port. The worker processes are spawned using the child_process.fork() method. The method returns a ChildProcess object that has a built-in communication channel that allows messages to be passed back and forth between the child and its parent.
we get the number of CPUs available with require('os').cpus().length
If it is not the master process, it is the child process, and there we call the startExpress function. This function is the same as the Express server in the previous example without clustering.
We create as many child processes as there are CPU cores on the machine the app is running. It is recommended to not create more workers than there are logical cores on the computer as this can cause an overhead in terms of scheduling costs. This happens because the system will have to schedule all the created processes so that each gets a turn on the few cores.

The workers are created and managed by the master process. When the app first runs, we check to see if it's a master process with isMaster. This is determined by the process.env.NODE_UNIQUE_ID variable. If process.env.NODE_UNIQUE_ID is undefined, then isMaster will be true.

If the process is a master, we then call cluster.fork() to spawn several processes. We log the master and worker process IDs. Below, you can see the output from running the app on a four-core system. When a child process dies, we spawn a new one to keep utilizing the available CPU cores.

As we can see, all eight CPUs have eight relevant workers running ready to take up any requests coming in. If we hit http://localhost:3000/api/:n we will see the following output, identical to the output from the previous non-clustering server

Load testing servers with and without clustering

To load test our Node.js servers with and without clustering, we will use the loadtest tool. Other options can be the Vegeta load testing or the Apache benchmark tool as well.
The loadtest package allows you to simulate a large number of concurrent connections to your API so that you can measure its performance.
To use loadtest, first install it globally:

npm install -g loadtest

Then run the app that you want to test with node app.js. We'll start by testing the version that doesn't use clustering.

With the app running, open another Terminal and run the following load test:

 loadtest http://localhost:3000/api/500000 -n 1000 -c 100

The above command will send 1000 requests to the given URL, of which 100 are concurrent. The following is the output from running the above command:

We see that with the same request (with n = 500000) the server was able to handle 786 requests per second with a mean latency of 121 milliseconds (the average time it took to complete a single request).

Let's try it again but with more requests this time (and with no clusters):

loadtest http://localhost:3000/api/5000000 -n 1000 -c 100

With a request where n = 5000000 the server was able to handle 183 requests per second with a mean latency of 517.1 milliseconds.

Let's compare this result with that of the app that uses clusters.

Below are the results for testing for http://localhost:3000/api/500000:

Tested with the same requests (when n = 500000), the app that uses clustering was able to handle 1051 requests per second — a significant increase, compared to the 788 requests per second of the app with no clusters. The mean latency of the clustered app is 91.2 milliseconds, compared to 121 of the app with no clusters. You can clearly see the improvement that clustering added to the app.

We'll run two more tests for each of our apps. We'll test requests that aren't CPU-intensive and that run fairly quickly without overloading the Event Loop.

With the no-cluster app running, execute the following test:
loadtest http://localhost:3000/api/50 -n 1000 -c 100

With the same no-cluster app still running, execute the following test:

loadtest http://localhost:3000/api/5000 -n 1000 -c 100
Here are the summarized results:

With the cluster app running, execute the following test:
loadtest http://localhost:3000/api/50 -n 1000 -c 100
The summarized results:

The clustered app ran 1482 requests per second compared to 1481 of the no-cluster one and had a mean latency of 64.2 milliseconds compared to 64.3 of the no-cluster one.

Let's run the other test. With the same cluster app still running, execute the test below:
loadtest http://localhost:3000/api/5000 -n 1000 -c 100
The summarized results:

Here, the clustered app ran 1475 requests per second compared to 1465 of the no-cluster one and had a mean latency of 65.2 milliseconds compared to 64.6 of the no-cluster one.

Based on those tests, you can see that clustering didn't offer much improvement to the app's performance. In fact, the clustered app performed a bit worse compared to the one that doesn't use clusters. How come?

In the tests above, we call our API with a fairly small value for n, which means that the number of times the loop in our code will run is considerably small. The operation won't be that CPU-intensive. Clustering shines when it comes to CPU-intensive tasks. When your app is likely to run such tasks, then clustering will offer an advantage in terms of the number of such tasks it can run at a time.

However, if your app isn't running a lot of CPU-intensive tasks, then it might not be worth the overhead to spawn up so many workers. Remember, each process you create has its own memory and V8 instance. Because of the additional resource allocations, spawning a large number of child Node.js processes is not always recommended.

In our example, the clustered app performs a bit worse than the no-cluster app because we are paying the overhead for creating several child processes that don't offer much advantage. In a real-world situation, you can use this to determine which apps in your microservice architecture could benefit from clustering — run tests to check if the benefits for the extra complexity are worth it.

References

Modifiers in solidity

tawseef nabi — Mon, 24 Jan 2022 15:05:58 +0000

Modifiers can be used to change the behavior of functions in a declarative way.
For example, you can use a modifier to automatically check a condition prior to executing the function. they can be used for:

Restrict access
Validate inputs
Guard against reentrancy hack

use the modifier in the declaration of a function.

Modifier to check that the caller is the owner of the contract

modifier onlyOwner {
   require(msg.sender == owner);
     // Underscore is a special character only used inside
     // a function modifier and it tells Solidity to
     // execute the rest of the code.
   _;
 }

Modifiers can take inputs. This modifier checks that the address passed in is not the zero address.

 modifier validAddress(address _addr) {
       require(_addr != address(0), "Not valid address");
       _;
   }

function changeOwner(address _newOwner) public onlyOwner validAddress(_newOwner) {
       owner = _newOwner;
   }

Modifiers can be called before and / or after a function.This modifier prevents a function from being called while,it is still executing.

 modifier noReentrancy() {
   require(!locked, "No reentrancy");
     locked = true;
     _;
     locked = false;
 }

 function decrement(uint i) public noReentrancy {
   x -= i;
   if (i > 1) {
     decrement(i - 1);
   }
 }

Mapping in solidity

tawseef nabi — Sat, 22 Jan 2022 07:29:52 +0000

Mapping in Solidity acts like a hash table or dictionary in any other language.

mapping(key => value) <access specifier> <name>;

keys are mapped to a value. Data isn't stored in a mapping, only its hash value.

key: any built-in types like uint , bytes, string except for a mapping, a dynamically sized array, a contract, an enum and a struct.
value: any type including mapping, struct, arrays

They don't have a length and you can't iterate through the mapping.
e.g.

// mapping declaration
mapping(uint => string )public people

// update mapping
 people[10] = 'Mark'; // assigns a value
people[12] = 'Andrew';

 // reading  values

people[1] // reads a value

 people[unknown_key]    //will return the default value of the type, i.e '' for string or 0 for unint

Assign an array as a map value
We can assign an array as a value type to a map and can access them as we would an array like below:

contract Mapping {

    mapping(address => uint[]) scores;    

    function manipulateArrayMap() external {
        scores[msg.sender].push(1);             //assign a value; 
        scores[msg.sender].push(2);             //assign another element

        scores[msg.sender][0];                  //access the element in the map array

        scores[msg.sender][1] = 5;              //update an element in the map array in index 1

        delete scores[msg.sender][0];           //delete the element in the index 0 of the map array
    }

}

Assign another map as a map value
We can also assign another map as a map value and can access them as we would access a map like below:

contract Mapping {

    mapping(address => uint) balances;
    mapping(address => mapping(address => bool)) approved;

    function manipulateMapOfMap(spender) external {
        approved[msg.sender][spender] = true                     //assign a value to the approved map
        approved[msg.sender][spender];                           //get the value of the map

        delete approved[msg.sender][spender]                     //delete the reference
    }

}

Common Use case
associate unique Ethereum addresses with associated unique values

Require vs Assert in Solidity

tawseef nabi — Sun, 02 Jan 2022 07:51:02 +0000

in Solidity version 0.4.10, the assert(), require()and revert() functions were introduced.
assert and require are convenience functions that check for conditions. In cases when conditions are not met, they throw exceptions.

require is used to validate inputs and conditions before execution.
assert is used to check for code that should never be false. Failing assertion probably means that there is a bug.
revert() is used abort execution and revert state changes

Syntax

assert(bool condition) causes a Panic error and thus state change reversion if the condition is not met - to be used for internal errors.

require(bool condition) reverts if the condition is not met - to be used for errors in inputs or external components.

require(bool condition, string memory message) reverts if the condition is not met - to be used for errors in inputs or external components. Also provides an error message.

revert() abort execution and revert state changes

revert(string memory reason) abort execution and revert state changes, providing an explanatory string

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.10;

contract Error {
    function testRequire(uint _i) public pure {
        // Require should be used to validate conditions such as:
        // - inputs
        // - conditions before execution
        // - return values from calls to other functions
        require(_i > 10, "Input must be greater than 10");
    }

    function testRevert(uint _i) public pure {
        // Revert is useful when the condition to check is complex.
        // This code does the exact same thing as the example above
        if (_i <= 10) {
            revert("Input must be greater than 10");
        }
    }

    uint public num;

    function testAssert() public view {
        // Assert should only be used to test for internal errors,
        // and to check invariants.

        // Here we assert that num is always equal to 0
        // since it is impossible to update the value of num
        assert(num == 0);
    }

    // custom error
    error InsufficientBalance(uint balance, uint withdrawAmount);

    function testCustomError(uint _withdrawAmount) public view {
        uint bal = address(this).balance;
        if (bal < _withdrawAmount) {
            revert InsufficientBalance({balance: bal, withdrawAmount: _withdrawAmount});
        }
    }
}

*Main Differences Between Assert vs Require In Solidity
*

** Behavior of assert and require functions**

The assert() **and require() **functions are a part of the error handling aspect in Solidity. Solidity makes use of state-reverting error handling exceptions.

This means all changes made to the contract on that call or any sub-calls are undone if an error is thrown. It also flags an error.
They are quite similar as both check for conditions and if they are not met, would throw an error.

Gas Utility

The big difference between the two is that the **assert() **function when false, uses up all the remaining gas and reverts all the changes made.

Meanwhile, a** require() **function when false, also reverts back all the changes made to the contract but does refund all the remaining gas fees we offered to pay.
This is the most common Solidity function used by developers for debugging and error handling.

Conclusion

To handle errors, Solidity undoes changes that might have caused issues.

assert checks for internal errors. require analyzes conditions.
Exceptions that Solidity revert generates can contain error strings