I am sorry, but to give a full answer I will have to get away a little bit what is being asked.
Your question lately refers to only one of the problems that web servers have
reply. This problem is Throughput (requests answered per unit of time (minutes)).
Remember that processing (code statements) is always done on a thread.
And this remains true when you are programming a web server, whose responsibility is as follows:
- Receive orders
- Process the request
- Send the answer
One particularity is that much of this processing is about I / O processing
(receive requests and send responses).
And while the I / O processing request is not resolved the CPU can continue processing the remaining requests.
But this can only happen if the I / O requests are made asynchronously .
Let's illustrate what happens in a synchronous and I / O asynchronous request, with 2 read requests to file A and B
and imagine that we want to search for a certain word in both files.
Asyoucansee,iftheprocessingisdoneasynchronously,thetotaltimewillbeshorter.Infactthetotaltimewillcorrespondtothefollowing:
Time=Max(I/OProcessingA,I/OProcessingB)+WordSearchinA+WordSearchinB
NowthatweknowwhyasynchronousI/Oprocessingisbeneficialwecanintroducebestpracticesthatshouldbefollowedbutalsowhendevelopingawebserver.
- AllI/Orequestsaremadeasynchronously.
- Ingeneral,athreadisneverblockedwaitingforI/O.
NowifanyonereadingthisanswerknowswhatI'veexplainedandknowstheNode,youknowthatalargeinvestmenthasbeenmadetoprovideAPIsthatprocessI/Orequestsasynchronously.However,inreadingfiles,forexample,youcandoitsynchronously.
AndthisiswhatallowstheNodetohavesuchalarge"throughput" only with one thread.
But in the end it is also the job of the programmer to ensure that there are no I / O requests to be made synchronously.
If this same practice is applied to other NEVER technologies, it is possible that only 1 thread can have a higher throughput of eg 4 threads on a 4-color CPU .
There may be many other reasons why one or another of the technologies may be better in one scenario, and that the Node may still perform better than another that is multi-threaded.
These reasons may be, but are not limited to:
- Implementation of virtual machines quite different
- Implementation of widely available APIs
- Interpreted language vs doubly compiled language
- ...
But this is not at all a limiting factor for the Node. For the same effect can be achieved by launching 4 processes from the same server and assigning them to different colors.
In this way the Node will also have the ability to use all the colors of a processor to handle the requests.
Because Node.js behaves with a relational database (postgres), the above system will probably have many queries to Bd, is this scenario compatible with the tool?
Guess, a query in the database is an I / O request. If it is done asynchronously, as I mentioned, it does not matter if it is done in Node or not.
Is Node.js made to work with sequential requests (make a request and wait for the return on the same "transaction")?
Two sequential requests can also be made asynchronously. The difference is that the second can only start when the first one is complete.
