JXcore, What's going on?

Posted On
About 10 months ago, we forked Node.JS and started building JXcore. Many people wondered what in the world we were doing by forking Node.JS. We have a big vision and a unique view of how programmers will develop applications in the future. We started by breaking that vision into many pieces that are closely tied. Node.JS is the central pieces of that vision. In this article, I will try to explain some of those pieces that we have completed and some others we are currently working on.

Soon, JXcore will be open sourced under the same license as Node.JS. It's been almost 10 months since we first started patching Node.JS in order to support multithreaded logical instances under the same process. During this time, we changed a very large part of the project sources in order to implement several key features. As a result we re-structured some key parts of Node.JS right from the beginning.

I'm going to come back to re-structuring part later but let me first explain the differences between Node.JS and JXcore. Node.JS, as defined from the main repository, is an asynchronous (evented) IO framework on top of V8 JavaScript engine. JXcore is a fork of Node.JS with additional features including support for multiple JavaScript instances for Node apps (using different threads under the same process). Soon (very soon) JXcore will offer an alternative JavaScript engine other than V8. So you can either use V8 (versions) or the other engine(s).

Since Node.JS is built on top of V8, it is no surprise that it inherits some habits like multiple processes instead multiple threads for managing separate logical parts. I have to admit, although V8 operates multiple JavaScript instances / threads properly, I was surprised by the number of developers against the idea of multiple threads when we came up with the first beta months ago. I believe the initial reaction was mostly because of a misunderstanding (or misleading) on the way we described our multi-threading support. What we implemented was a capability to allow multiple separated logic instances benefiting from multiple cores, not making JavaScript work multi-threaded.

Another challenge facing Node.JS developers is the hosting situation. We believe the difficulty of hosting Node.JS applications is a major problem that needs to be addressed. I have years of .NET experience and in my opinion Node.JS is a powerful platform that you can develop enterprise level applications in a shorter time than ASP.NET. On the other hand, hosting an ASP.NET application requires less technical background and it is much smoother to manage. There are many hosting alternatives compared to hosting a Node.JS application and I'm not even comparing the cost of hosting Node versus ASP.NET. This has to change! Indeed, ASP.NET is around for almost a decade but there are technical reasons for the problems instead being around for a longer period of time.

Last month, we released a free Parallel Plesk Node.JS extension hoping to make Node.JS hosting options available to a larger audience and make it cost effective. The extension is getting better with the updates thanks to Plesk team and its users. Hopefully, small companies and the individual Node.JS developers will find these hosting options useful for their web applications.

In order to develop the Plesk extension, we implemented some key features to make it easier to host a Node.JS application (Multithreading, monitoring, system wide application configuration as you can limit CPU, memory etc) similar to hosting a PHP or ASP.NET application. Coming weeks, we will have an alternative approach to host Node.JS applications easier, and cost effective than ever.

NPM (Node Package Manager) hosts thousands of modules developed by individuals and companies to add additional features to Node. Indeed, NPM is one of coolest package managers. The growth rates of NPM modules is a clear proof. But there are problems not exactly caused by NPM rather how Node.JS have been evolving. There are many Node.JS applications still using version 0.6 and 0.8. Having different versions of V8 makes it almost impossible to develop and compile native Node modules once and for all. It is clear that some module developers may not follow the latest Node versions and keep their modules compatible. As most of the community knows, NPM now includes many outdated packages which would otherwise be very useful. Since we are going to open source JXcore with multiple JavaScript engine option, re-structuring the native module development was inevitable. 

Node.JS has it's own way of dealing with incompatible modules. If a native modules uses 'nan', it has a better chance to survive over multiple releases unless the module doesn't use some critical (non-standard) stuff from the JavaScript engine. And unfortunately, 'nan' may not handle multiple JavaScript engines or pre-compiled binaries per platform. Implementing 'nan' was a very clever hack. But it is still a hack. As the user base of Node.JS grows, a more proper solution must be implemented. In JXcore, we are in the process of completing an interface which will work with multiple JavaScript engines and still be compatible to multiple JavaScript instances per process.

Hopefully, the concept of multiple JavaScript engines will convince more enterprises transition to using Node. One of the key advantages of supporting multiple JavaScript engines is being able to deploy Node applications on mobile platforms. But we are thinking even further. We believe JavaScript will be the best choice for the Internet of Things as we already see some practical usages. We hope to make HTML, CSS, and JavaScript native citizens for all platforms.

As Node applications are deployed on mobile and embedded devices, programmers are faced with the challenge of protecting their JavaScript source code. One option is to "uglify" your source code and hope that nobody will try to extract your code. For many companies this is not even an option. That's one of the reasons why we implemented JXcore packaging feature which protects your source code and instantly creates a package that works on every platform. 

And mobile IDEs. Based on JXcore mobile, Node.JS will be a unique platform with its own IDEs working on mobile devices.  We want to make Node.JS application development easier from development to hosting for every level of developers.

Parts of what I described here is already available. Others will be released over the course of next few months. But this is only part of our overall vision. Stayed tuned for more...
[Read more]

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]