Reviewing “Instant Node.js Starter” by Packt Publishing

I’m pleased to announce that I will be one of  “Instant Node.js Starter” book reviewers, a new book from Packt Publishing, authored by Pedro Teixeira. I will publish my review results at the end of this month and you can read them from Amazon and Packt website.

5569OS_Microcov

 

Packt Publishing starts to publish and write mini-books for many subjects and NodeJs is one of them. NodeJs is a young topic in programming environment and these kind of books are really helpful to getting started with it easily, in the shortest time. Click here to read more or buy this book.

Big kudos to Pedro Teixeira for his effort to write this book and many thanks to Packt Publishing to help programmers for getting started easily by publishing these kind of nice resources.

How to fix “couldn’t open /data/db/something.ns errno:13 Permission denied” error in MongoDB

When you’re working with MongoDB, sometimes you may face with rare errors that solving them may causes headache. One of them is errno:13 Permission denied when MongoDB server crashes or shutdowns suddenly. For solving this problem there are some simple steps.

First of all go to /data/db and list all databases, here you can see all databases in your MongoDB server. I have one database here, called sourcedoc.

[root@srv7518 ~]# ls -ls /data/db
0 -rwxr-xr-x 1 mongod mongod 0 May 21 10:50 mongod.lock
4 drwxr-xr-x 2 root root 4096 May 21 10:46 sourcedoc
16404 -rw——- 1 root root 16777216 May 21 10:46 sourcedoc.0
32804 -rw——- 1 root root 33554432 May 21 10:46 sourcedoc.1
16404 -rw——- 1 root root 16777216 May 21 10:46 sourcedoc.ns

As you can see, the owner of sourcedoc is root and that’s actually the problem. We should change it to proper user in the system, so follow this step now. We should change the owner to mongod user to solve the permission problem, so simply run chown command with root permission (using sudo).

[root@srv7518 ~]# sudo chown -R mongod /data/db

You don’t get any message from this command and after running that, we run ls command again to make sure everything is fine now:

[root@srv7518 ~]# ls -ls /data/db
0 -rwxr-xr-x 1 mongod mongod 0 May 21 10:51 mongod.lock
4 drwxr-xr-x 2 mongod root 4096 May 21 10:46 sourcedoc
16404 -rw——- 1 mongod root 16777216 May 21 10:46 sourcedoc.0
32804 -rw——- 1 mongod root 33554432 May 21 10:46 sourcedoc.1
16404 -rw——- 1 mongod root 16777216 May 21 10:46 sourcedoc.ns

And the owner of sourcedoc file is mongod now. Then we should start the service again.

[root@srv7518 ~]# sudo service mongod start
Starting mongod: all output going to: /var/log/mongo/mongod.log
forked process: 23726
child process started successfully, parent exiting
[ OK ]

Done.

Async vs. Sync I/O benchmark in NodeJs

As you know, NodeJs is a non-blocking I/O platform which gives you ability to do non-blocking and event-based functionalities. It has async methods for I/O but it also provide sync version of that methods as well. It means you can write to a file with async/non-blocking methods and you can do the same with sync methods.

So, in this post I want to show you the different between using async or non-blocking I/O  and sync I/O. Here I have a HTTP server which has a simple functionality, it just reads a static file from disk and gives the content of file to the user by an HTTP request. There’s two different ways for reading a file from disk in NodeJs, with fs.open (async) or fs.openSync (sync).

Results speak for themselves, as expected. When we try to read a file with Async mode, all steps of reading a file (stat, open, read, close) are async and it means the reading process will not block the request (less request time) but in Sync mode, each step should wait for previous step result so it takes more than Async mode.

I used Apache Benchmark (ab) for these tests, with this parameters:

ab -n 1000 -c 1000 -vhr http://localhost:8081/

And the test system is:

CentOs, Linux 2.6.18-164.el5 and NodeJs v0.8.8, 512MB Memory, QEMU Virtual CPU.

Well, let’s see the results.

Async mode:

Time taken for tests: 3.800 seconds
Requests per second: 263.19 [#/sec] (mean)
Time per request: 3799.512 [ms] (mean)
Time per request: 3.800 [ms] (mean, across all concurrent requests)

Percentage of the requests served within a certain time (ms)
50% 2667
66% 2682
75% 3752
80% 3752
90% 3761
95% 3765
98% 3765
99% 3765
100% 3765 (longest request)

Sync mode:

Time taken for tests: 4.809 seconds
Requests per second: 207.95 [#/sec] (mean)
Time per request: 4808.944 [ms] (mean)
Time per request: 4.809 [ms] (mean, across all concurrent requests)

Percentage of the requests served within a certain time (ms)
50% 2418
66% 3152
75% 3585
80% 3827
90% 4320
95% 4551
98% 4712
99% 4760
100% 4809 (longest request)

You can see that in the Async mode you can process about 264 requests per second while in Sync mode it’s about 208.

I made this test to show the power of Async I/O functions in NodeJs and also to show the NodeJs developers that using Sync I/O functions is not a good solution for Callback Hell, there are several better approaches to solve the Callback Hell problem, keep using Async functions.

You're doing it wrong

You’re doing it wrong

You can download and run this test yourself, I made a Github repo, here you can download them: https://github.com/afshinm/Async-Sync-IO-benchmark

MongoDB singleton connection in NodeJs

In this post, I want to share a piece of useful source code to make a singleton connection in NodeJs. By using this piece of code, you will have always one connection in your NodeJs application, so it will be more faster. Also, if you are using NodeJs frameworks like ExpressJs, it will be useful too.

connection.js:

var Db = require('mongodb').Db;
var Connection = require('mongodb').Connection;
var Server = require('mongodb').Server;
//the MongoDB connection
var connectionInstance;

module.exports = function(callback) {
  //if already we have a connection, don't connect to database again
  if (connectionInstance) {
    callback(connectionInstance);
    return;
  }

  var db = new Db('your-db', new Server("127.0.0.1", Connection.DEFAULT_PORT, { auto_reconnect: true }));
  db.open(function(error, databaseConnection) {
    if (error) throw new Error(error);
    connectionInstance = databaseConnection;
    callback(databaseConnection);
  });
};

And simply you can use it anywhere like this:

var mongoDbConnection = require('./lib/connection.js');

exports.index = function(req, res, next) {
  mongoDbConnection(function(databaseConnection) {
    databaseConnection.collection('collectionName', function(error, collection) {
      collection.find().toArray(function(error, results) {
        //blah blah
      });
    });
  });
};

Now, you will have only one connection in your NodeJs application.

Download codes from Gist:

Let me know what you think :)

NodeJs, MongoDB and RangeError: Maximum call stack size exceeded

If you’re using NodeJs with Native MongoDB driver and see the RangeError: Maximum call stack size exceeded error while working with the MongoDB, this post will probably help you.

If you’re trying to save a document and saving process somehow exited with an RangeError: Maximum call stack size exceeded exception, it’s related to what you want to save in the database. I had this problem also, and when I checked my object, I found that the problem is related to the big DOM Object that I included in the object, and when I removed that, the object saved in MongoDB correctly.

Here is a piece of my buggy code:

collection.insert({
  seq: nextSeq,
  profileIdentity: profileIdentity,
  sectionData: secData, //the problem is here, in `secData` object 
  findDateTime: new Date()
});

The problem occurred in `secData` array. In the second item of that array I had a big DOM Object and after removing that object from array (and of course, doing that job in a different way), problem solved.

In some posts in MongoDB’s forum I saw that peoples said saving in `process.nextTick` or wrapping the call function in `parseInt` will also fix the problem, but it’s not work for me, however, check these posts also:

 

Understanding JavaScript chaining structure

In this post, I want to talk about JavaScript chaining structure, how it works and why we should use it?

What’s the chaining structure?

You may used some JavaScript libraries that has an API like this:

booJs().setOption("first", 1).goTo(2).start();

those plugins or modules, follow a principle that called JavaScript chaining method, so you can call methods after each other, just like a chain.

For giving a broad picture of this structure, see this code, this is the non-chaining method of the previous code:

var booInstance = booJs();
booInstance.setOption("first", 1);
booInstance.goTo(2);
booInstance.start();

As you can see, with chaining methods we have smaller code size and more human readable source code, isn’t that better?

How it works?

So now I want to show how it works actually, it’s quite simple. See this piece of code:

var booJs = function() {
  var _setOption = function(key, value) {
    console.log("Set " + key + " to " + value);
  };
  var _goTo = function(step) {
    console.log("Go to step " + step);
  };
  var _start = function() {
    console.log("Whohooo, engine started!");
  };
  //Public API
  return { 
    setOption: _setOption,
    goTo: _goTo,
    start: _start
  };
};

This is a simple code, with some private methods and a public API. Suppose we want to do these three steps:

  1. Set option first to the 1 with setOption method
  2. Going to step 2 with goTo method.
  3. Then start the engine with start method.

So we should do:

var booInstance = booJs();
booInstance.setOption("first", 1);
booInstance.goTo(2);
booInstance.start();

And we will get this result:

Set first to 1
Go to step 2
Whohooo, engine started!

Let’s re-write that simple library with chaining structure, all we need to do is return the current instance of booJs in each methods, so final library will we something like this:

var booJs = function() {
  var _setOption = function(key, value) {
    console.log("Set " + key + " to " + value);
    return this; //return current instance of booJs here
  };
  var _goTo = function(step) {
    console.log("Go to step " + step);
    return this; //return current instance of booJs here
  };
  var _start = function() {
    console.log("Whohooo, engine started!");
    return this; //return current instance of booJs here
  };
  //Public API
  return { 
    setOption: _setOption,
    goTo: _goTo,
    start: _start
  };
};

And now we can use the API this way:

booJs().setOption("first", 1).goTo(2).start()

result also will be the same of non-chaining structure.

Conclusion

By using chaining method in JavaScript, we will have simple API and more human readable code, but I personally don’t prefer long chains in methods.

All we need to do for creating chaining methods is to return the current instance of library in each methods, so after calling every methods of library we have the created instance of the library and all other methods are available and can be called after calling methods.