Based on my understanding, only I/O in NodeJS is non-blocking. If we do, for example, lots of heavy math operations, other users cannot access to the server until it's done.
I was wondering if there is a non-blocking way to do heavy computation in NodeJS? Just curious.
If you have long-running calculations that you want to do with Node, then you will need to start up a separate process to handle those calculations. Generally this would be done by creating some number of separate worker processes and passing the calculations off to them. By doing this, you keep the main Node event loop unblocked.
On the implementation side of things, you have two main options.
The first being that you manually spin off child processes using Node's child-process API functions. This one is nice because your calculations wouldn't even have to be javascript. The child process running the calculations could even be C or something.
Alternatively, the Web Worker specification, has several implementations available through NPM if you search for 'worker'. I can't speak to how well these work since I haven't used any, but they are probably the way to go.
Update
I'd go with option one now. The current child process APIs support sending messages and objects between processes easily in a worker-like way, so there is little reason to use a separate worker module.
You can use Hook.io to run a separate node process for your heavy computation and communicate between the two. Hook.io is particularly useful because it has auto-healing meshes meaning that if one of your hooks (processes) crashes it can be restarted automatically.
Use multiple NodeJS instances and communicate over sockets.
Use multiple node instances and communicate over node-zeromq, HTTP, plain TCP sockets, IPC (e.g. unix domain sockets), JSON-RPC or other means. Or use the web workers API as suggested above.
The multiple instances approach has its advantages and disadvantages. Disadvantages are that there is a burden of starting those instances and implementing own exchange protocols. Advantages are that scaling to many computers (as opposed to many cores/processors within a single computer) is possible.
I think this is way to late, but this is an awesome feature of nodejs you've to know about.
The only way abot multithreading is by spawning new processes, right so far.
But nodejs has an implemented message feature between spawned node-forks.
http://nodejs.org/docs/latest/api/child_processes.html#child_process.fork
Great work from the devs, you can pass objects etc. as message to your childs and backwards
You can use node cluster module.
https://nodejs.org/api/cluster.html
I would use JXCore - it's a polished nodejs based engine which runs your code but has several options including the multi threading you are searching for. Running this in production is a charm!
Project's source: https://github.com/jxcore/jxcore
Features include:
Support for core Node.JS features
Embeddable Interface
Publish to Mobile Platforms (Android, iOS ..)
Supports Multiple JavaScript Engines
Multi-threading Capabilities
Process Configuration & Monitor
In-memory File System
Application Packaging
Support for the latest JavaScript features (ES6, ASM.JS ...)
Support for Universal Windows Platform (uwp) api
Related
https://www.npmjs.com/package/threads
It seems to me we can use this package in Angular for running threads.
But I feel difficulties on implementing this.
Is there anyway to use threading in Angular?
How can I use thread in Angular?
Angular does not have "threads", which by the way can mean many different things, in different contexts, environments, platforms, CPUs, and operating systems. Threads can be a way to accomplish parallelism; or they can be a way to organize your code as a set of concurrent processes; or they can be a way to manage access to shared resources; or any or all of the above.
Angular works in a browser. Browsers run JavaScript. The closest thing we have to threads in our browser world is web workers. To greatly oversimplify, web workers are not light-weight threads; in other words, you wouldn't want to create 100,000 of them. But if you are looking for a simple way to offload some computation away from the main browser task, so that it does not lock up the browser while you are computing, then you are probably interested in web workers.
Web workers do not really need any special library, or wrapping, or scaffolding. They're easy enough to just write directly. However, if you're interested in some ways to facilitate the process of using web workers within an Angular context, then google for "angular web workers".
I have no special knowledge of the library you mention. At first glance, it appears to be a way to abstract concurrent algorithms over different threading implementations appropriate for the node.js platform vs. the browser. If you're planning on working in Angular, then most likely the node.js platform part is irrelevant, so this entire library is not anything you should be interested in.
JavaScript is strong with me. .NET, notsomuch...
I'm trying to figure out edgeJS on NodeJS and while I've got some sense of how to patch together communication between the two I can't seem to figure out how to maintain a listener in NODE for my Edge functions to send events to. I can only seem to get my functions to fire and hand off control to Edge while the function is running, but I would like Edge to tell NODE to do something basic for starters like console.log in NODE instead of Console.Write in .NET.
Is there an example out there that can help me? The Edge documentation seems to be above my head in this regard.
Thanks!
Disclaimer - I am new to Edge JS.
But Edge Js is for in process communication not cross process. When you say you would like to call console.log in node js - what I thought you want is call an independent nodejs application from C# ? I don't think that is possible using Edge js but you can always make http call and host a web service and that is what is shown in one of the performance graph that the in process and out of process calls difference.
Quoting from InfoQ article. Which shows we are talking about in process communication where the code of ne is nested in another and not separate.
There are two main benefits of using Edge.js to run Node.js and .NET in one process instead of splitting the application into two processes: better performance, and reduced complexity. Performance measurements of one scenario show that in-process Edge.js call from Node.js to C# is 32 times faster than the same call made using HTTP between two local processes. Dealing with a single process instead of two processes with a communication channel between them reduces the deployment and maintenance complexity you need to handle.
Is Node.js mature enough to make entire web applications in it? I mean entirely in Node.js. I read somewhere that for some reason there should be (for example) nginx behind Node.js. Is it true? Can't Node.js stand alone? Are there any online websites built on Node.js?
in my opinion this isnt true anymore.
you can do two things:
use script like "forever" to monitor your node instance.
use this:
http://nodejs.org/docs/v0.4.12/api/process.html#event_uncaughtException_
to catch all exceptions that are not catched earlier
In the express link, it shows a lot of good applications written by Node.js.
In my opinion, it is mature enough that node.js can be a standalone web application server. There are lots of lib modules supported different things in Nodejs already.
Its absolutely mature enough. There are dozens of companies now that are using it in production for major features, and some that are even building their entire stacks with it.
If you want a well-rounded web framework, check out Express.
There are hundreds of modules that cover almost every type of feature you need, and they're mostly all easily accessible via npm (node package manager).
Over the summer I built a high-traffic Facebook app for a client using Node. Handles everything just fine.
node v0.6 introduced cluster, allowing multiple processes to fork and listen to a single socket. This allows node to take advantage of multiple cores/cpus. This was one of the big reasons to use something like nginx, as before cluster, a single node process would hog up an entire ip/port.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to decide when to use Node.js?
Sorry if I'm a bit ambiguous, but I'm trying to understand the real advantages of using Node.js instead of other server-side language.
I'm a JavaScript enthusiast, so I'm probably going to play with Node.js, but I want to know if I should use it in my projects.
It's evented asynchronous non-blocking I/O build ontop of V8.
So we have all the performance gain of V8 which is the Google JavaScript interpreter. Since the JavaScript performance race hasn't ended yet, you can expect Google to constantly update performance on V8 (for free).
We have non-blocking I/O which is simply the correct way to do I/O. This is based on an event loop and using asynchronous callbacks for your I/O.
It gives you useful tools like creating a HTTP server, creating a TCP server, handling file I/O.
It's a low level highly performant platform for doing any kind of I/O without having to write the entire thing in C from scratch. And it scales very well due to the non-blocking I/O.
So you want to use Node.js if you want to write highly scaling and efficient applications using non-blocking I/O whilst still having a high level scripting language available. If needed, you can hand optimise parts of your code by writing extensions in C.
There are plenty of OS libraries for Node.js that will give you abstractions, like Express.js and now.
You don't want to use Node.js if you want (slow) high level abstractions to do everything for you. You don't want to use Node.js if you want RAD. You don't want to use Node.js if you can't afford to trust a young platform, either due to having to write large pieces of code yourself to do things that are build into other frameworks or because you can't use Node.js, because the API isn't stable yet or it's a sub 1.0 release.
The two most oft-quoted advantages are:
JavaScript is both server-side and client-side. There are fewer things to learn, less context switching, and the ability to reuse code across the two sides.
Uses non-blocking I/O, and Chrome's V8 engine, to provide fast, highly scalable servers.
For me though, the most interesting part is the amount of activity happening in this area. There are a lot of very interesting ideas under development for node - be sure to check out the list of Node.js modules.
When you're (or even if you are not) a JavaScript enthusiast you can/should use Node.js for a number of reasons:
It's a low-level, lightweight and standalone framework which brings power of JavaScript to the server-side environment.
If you like more higher level abstraction then there is a large number of modules and the npm package manager where you can find wide range of ready-to-use applications.
Fast/unencumbered development process - for example, you don't need tons of additional tools in order to start writing serious stuff.
Big open source based community full of enthusiasts and very talented people.
Made for creating real-time web oriented applications - that's where the (near) future is.
Personally, I'd most likely use Node.js when:
I want to write a server that doesn't use the HTTP protocol.
I'm prototyping a server implementation.
I'm writing a server that isn't expecting a ton of traffic (although I've never profiled a Node.js implementation next to, say, a matching C++ implementation).
I want to get active in the community (which is apparently growing quite rapidly).
how to impove game-server performance with mutil-core cpu
My point:
one busy process make one core busy, if only one busy process, very bad.
multi-process process and listen on diffrent port imporved concurrency connections
multi-process can't share the memory data directly. they need communicate.
they can communicate in socket, fp socket, and redis
seperate game-server into diffrent functions, each function a standalone process, some function can be parrallel processes.
if my point is correct, my question is:
what's the best way to communicate between processes, and keep the data synchronized, the best means fast and simple.
I am using nodejs, but I think it's the same with c for this topic.
Edit:
Sharding or seperate by functions , which is better
There are many discussions about that available on internet so I am just joining the links instead of repeating what they say:
Use Threads Correctly = Isolation + Asynchronous Messages
Use Thread Pools Correctly: Keep Tasks Short and Nonblocking
Break Up and Interleave Work to Keep Threads Responsive
Sharing Is the Root of All Contention
Design for Manycore Systems
These links show the best practices to create a safe and well designed parallel solution.
I would advice to create a pool of threads to handle the connections. One thread per connection. That's the common "pattern" for servers.
One method for node.js is to use ØMQ, which allows you to communicate between threads, processes, and servers with the same simple BSD sockets compatible API.
Here's the node.js binding to try:
https://github.com/JustinTulloss/zeromq.node