Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the meaning of I/O intensive in Node.js

Tags:

node.js

I was learning Node.js and also found out that Node.js is best to be used with I/O intensive tasks which confused me a bit. So, after some research I found this statement: "An application that reads and/or writes a large amount of data". So, does it mean that Node.js is best to be used with data, that is, read big data, take necessary data from that and send back to client?

like image 592
SAM Avatar asked Apr 25 '20 05:04

SAM


People also ask

What is data intensive in node JS?

Node. js uses non-blocking, event driven I/O to offer efficiency and remain lightweight in terms of in-memory usage to data intensive real time web applications that run in various distributed environments or devices.

What is I O in Nodejs?

I/O (input/output) Short for input/output, I/O refers primarily to the program's interaction with the system's disk and network. Examples of I/O operations include reading/writing data from/to a disk, making HTTP requests, and talking to databases.

What are IO intensive applications?

An application that reads and/or writes a large amount of data. The performance of such an application depends on the speed of the computer's peripheral devices.

Is node js resource intensive?

Nodejs is good for IO intensive tasks but bad for CPU intensive tasks. The reason Nodejs is bad for CPU intensive task is that it runs on the event loop, which runs on a single thread. The event loop is responsible for everything that runs on the user-land of Nodejs. This event loop runs on a single thread.


1 Answers

A nodejs application can be architectured just fine to include non-I/O things and is not just suited for big data applications (in fact big data has nothing to do with it at all).

A default, simple implementation of Node.js performs best when your application is not CPU intensive and instead spends most of its time doing I/O (input/output) tasks such as reading/writing to a database, read/writing from files, reading/sending network data and so on. It's not about big data, it's about what does the server spend most of its time doing.

Surprisingly enough (to some) since a web server's primary job is responding to http requests which are usually requests for data, most web servers spend most of their time fetching things, reading and writing things and sending things which are all I/O tasks. In the node.js design, all these I/O tasks happen asynchronously in a non-blocking fashion and they use events to signal when those operations complete. This is where the phrase "event-driven design" comes from when describing node.js. It so happens that this makes node.js very efficient at handling things that involve primarily I/O. This is what a simple implementation of node.js does best. And, it generally does it better than a purely threaded server design that devotes an OS thread to every currently in-flight I/O operation (the original design for many server frameworks).

If you do have CPU intensive things (major calculations, image processing, heavy crypto operations, etc...) and you do them very often or they take very long, then you will be best served if you put those tasks in a Worker Thread or in another process and communicate back and forth between the main process in node.js and this worker to get that CPU-intensive work done. It used to be that node.js didn't have Worker Threads which made this task a little more complicated where you often had to use one or more additional processes (either via clustering or additional dedicated processes) in order to handle this CPU-intensive work, but now you can use Worker Threads which can be a bit more convenient.

For example, I have a server task that requires a very heavy amount of crypto (performing a billion crypto operations). If I put that in the main node.js thread, that essentially blocks the event loop so my server can't process other requests while that heavy duty crypto operation is running which would ruin the responsiveness of my server.

But, I was able to move the crypto work to a worker thread (actually to several worker threads) and then can crunch away on the crypto while my main thread stays nice and lively to handle other, unrelated incoming requests in a timely fashion.

like image 177
jfriend00 Avatar answered Sep 30 '22 18:09

jfriend00