How to measure the CPU usage of a Node.JS / JXcore Application

Posted On
JXcore has a non-documented utility class with several handy methods / features. We didn't published a documentation for the utility members yet, since they are mostly used internally and not designed for general use cases.

Knowing that not much option available for cross platform node.js process CPU tracking, I wanted to share a small sample that may help developers looking for it. If you don't have it yet, visit jxcore.com/downloads to download latest JXcore and run the below sample for CPU usage tracking;

// console color support. 
console.log = jxcore.utils.console.log;

// get CPU usage every 1000ms 
jxcore.utils.getCPU(function (percent, timer) {
    console.log("%d%% CPU Percent Used in last %d ms", percent, 
                        timer , "green");
}, 1000);

Beware that getCPU method only supports a single listener instance at a time. In order to clear the previous listener;

jxcore.utils.getCPU(); 

To read the CPU usage for only once, use above line of code inside the callback function.

There are many alternatives for colored console output though. If you still insist using the one from jxcore.utils, feel free to check ANSI COLOR node module for a color reference. The only difference is that jxcore.utils.console.log works similar to console.log hence it supports multiple parameters..
[Read more]

Monitoring Node.JS applications using JXcore

Posted On
One of the most common concerns with Node.JS based server apps is to keep the process running as long as the hosting server is up an running. Since the whole node.js application is based on a single process, you may need to make sure that process is alive even after the unexpected crashes etc.

Simply download JXcore from http://jxcore.com/downloads/  and locate the 'jx' binary into the system path or where the node binary is located. Assuming the application needs monitoring has a main JavaScript file named 'app.js'

first of all start monitor service:
$ jx monitor start

register the application into monitoring service and run:
$ jx monitor run app.js

That's it! You can kill your application's process from 'terminal' or 'console' etc. in order to see what will happen. As soon as the process is closed, JXcore monitoring service will be restarting it.

If your application requires some command line parameters (i.e param1)
$ jx monitor run app.js param1

In order to stop monitoring service (also stops spawned processes)
$ jx monitor stop
[Read more]

How Node.JS applications will benefit from replacing V8 in JXcore

Posted On
When we started implementing a multi-threading support to our node.js fork, the initial reason was to improve general application performance, make node.js handling cpu heavy tasks, and keep the application from unknown pauses. There were other reasons like heap memory limitation, lower system resource for sub instances etc. but obviously they were relatively easy to solve using other tools and approaches.

(more about JXcore)

1 ) node + V8 combination may not be the fastest combination anymore..

Some time ago, I did a basic benchmark using V8's benchmark files in order to compare the performance of V8 combined with nodeJS 10, and nodeJS 12(beta11).  You can run the benchmarks using this JavaScript file on both of them.

Here are the results:
**node.JS 10 / JXcore (engine: v8 ~14)**
Richards: 16913
DeltaBlue: 20655
Crypto: 21709
RayTrace: 19866
EarleyBoyer: 29623
RegExp: 5423
Splay: 5574
NavierStokes: 25448
----

Score (version 7): 15558
real 0m19.328s
user 0m19.252s
sys 0m0.252s


**node.JS v12 (engine: v8 ~26)**
Richards: 25449
DeltaBlue: 41403
Crypto: 25926
RayTrace: 24223
EarleyBoyer: 27759
RegExp: 5637
Splay: 11156
NavierStokes: 27224
----

Score (version 7): 20521

real 0m24.328s
user 0m24.252s
sys 0m0.154s



The difference in performance is up to 30 percent (I should test it on other platforms too). I don't know anybody expects this much performance loss while moving to a never node.JS version but it was a surprise to me. (I'm going to update the numbers when I have a chance to get the results from others)

(notice: the reason for running given benchmark is not to measure octane results, instead measuring IO-free performance of a cpu bound app. Any other JavaScript file can be used here. It was also useful to see the situation with experimental engine. The benchmark results doesn't suggest anything but clearly latest v8+node combination doesn't bring a performance gain over the old one although the scores showing otherwise - weird problem though)

What we were trying to do right at the beginning was to make node.JS apps more efficient with CPU heavy ops but it seems the direction of V8 wasn't going to let us to do that properly (see below 2nd item). Indeed, the developers will expect using latest JavaScript features on their apps but considering the performance cost, it may not match the expectations on the server side JavaScript. The result below is from an experimental engine with the latest JavaScript features.

**JXcore (experimental engine / supports latest JavaScript features)**
Richards: 18332
DeltaBlue: 18989
Crypto: 23034
RayTrace: 27824
EarleyBoyer: 35711
RegExp: 4415
Splay: 19753
NavierStokes: 21263
----
Score (version 7): 18672
real 0m21.328s
user 0m21.252s
sys 0m0.212s



It may not be the faster than the combination used in JXcore / node.JS 10, but still ~15% faster than the latest one and it has the latest features expected by the developers. 


2 ) Unexpected application pauses when you reach the certain number of total objects

I was simply experimenting with the total memory limits on the experimental engine and compare the results with JXcore / node.JS (10 and 12) using V8. Indeed V8 has known memory limitations but honestly, especially for 64 bit systems using external memory modules or simply using JXcore, these memory limits were not critical to keep developers from using it in large scale applications. The test file is available from here. To run the test file simply call ($ jx object_limits.js ) or ($ node object_limits.js )

You may not expect a node.js application to have very big arrays or dictionaries and still be responsive. But considering all third party modules, node's own native parts and your application's logic, you will end up with thousands of relatively "big" objects inside the memory. On the other hand the test case simply depends on a text "Hello World". Actually, it was a bigger object to test heap memory in the beginning but later I replaced it with a simple one since the problem wasn't really the memory limit.

Let me share what happens when you run the test case with (4);

STARTING LOAD 1
0 - 0.902634
1998000 - 1.95929666
PART2
0 - 0.1915308
1998000 - 6.380763793
PART3
0 - 0.1357434
1998000 - 20.670028727


The application stops responding twice (first one is for 6 sec and the second one is for 20!) yet the total memory usage nowhere close to any memory limitation of V8. In case of an application hosting users, the logical part won't be answering the requests while concurrent requests keep queuing and causing the app to have more breaks until it crashes.

If you try the same case using JXcore's multithreading approach ($ jx mt-keep:4 object_limits.js 1) and divide the load into 4 threads, everything will work smoothly as expected but still this doesn't explain or give any control to developer to overcome the issue in the bigger picture. Indeed, we all know that, we shouldn't keep many objects on the V8 heap and use external memory as much as possible (i.e. JXcore's memory store) But nobody knows to what end!

This problem applies to both new and old V8 and anyone wishing to dig into this problem more will find an easier way to trigger this issue.

Note that, we are open sourcing JXcore soon hopefully with an engine more suitable for server side usage and compatible with mobile devices including (Windows RT and IOS). Stay tuned!

[Read more]

JXcore combines SQLite and Node.JS for Raspbian

Posted On
Compiling Node.JS on Raspberry PI unfortunately takes lots of time (approx. 4 hours!!) assuming there will be no problem with the compilation process. Besides, there is a compilation issue with upcoming node.JS on raspberry PI and it can be really annoying especially waiting hours for it! For this and many other reasons, we released JXcore binary for Raspberry PI.

If you want to use the latest Node.JS on Raspbian and also benefit from the cool features of JXcore, you can visit the download page from http://jxcore.com/downloads and start developing node.js on Raspbian.

Days before the release we hosted our messaging API on a small Raspberry PI board. It was really nice having our mobile phones talking to each other with a remote PI board + JXcore through its messaging api. I don't want to start a new benchmark war but JXcore is unbelievably faster than the pre-installed Python on Raspberry PI. Interested developers can start hacking their boards using JXcore. I think I might have my own embedded idea with JXcore!!

Lastly, since JXcore also has an embedded module installer helper, you can simply run: '$ jx install npm' to install npm or '$ jx install express' for the hosted packages (i.e. express)

Enjoy!
[Read more]