php and nodejs, the difference on the fingers
Being a regular user of the nodejs.ru forum, I often observe a picture when people starting to learn nodejs compare it with php, and sometimes try to work with it as with php. I would like to explain “on fingers” the difference between php and nodejs in relation to the work of the site. This article is intended for beginners. I will deliberately speak in a very simplified way, without going into deep details, in order to show the differences in technologies as simply as possible.
It is always better to explain something by a clear example with pictures. Therefore, let's invent a small “spherical site in a vacuum” and accept some conditions.
Suppose we have a site that understands only two requests:
Request A is executed in 1 second, it does not require access to the database.
Request B is executed in 5 seconds, and 4 of them, it spends waiting for the response of the database.
We also agree that the time between requests is at least 1 second.
Let's take a look at how this works on php.
In its most simplified form, the server architecture looks like this:
')
The following is important here, the web server receiving a request from the client sends it to the php process. In turn, the php process can process one request at a time, upon completion of the work, the result is returned to the web server, and the process itself ceases to exist. The web server receiving the response sends the result to the client and closes the connection.
If there is only one php process, the work of our server can be displayed on this scheme:
It is clear from the diagram that as long as only requests come to us, our server responds to them vigorously and generally performs its tasks, but as soon as request B comes to us, the server stops responding to requests until the answer to request B is ready. Also on the diagram you can see that most of the time query B, “everyone” waits for the result of the database operation.
To solve this problem, we have to increase the number of php processes, let's increase to 2x, as a result, the scheme takes the following form:
From this scheme, it is clear that request B “hangs” in processing in the first php process, while the server continues to respond to other requests. Everything will go well until the moment when two requests B come to us, then both php processes will “hang” waiting for the base to respond, and the server as a whole will stop responding until one of them is free.
Well, we already know what to do? That's right, let's take and increase the number of php processes, immediately to 20 or 30 and the problem seems to be gone, although in fact the problem just drifted away a bit and the moment when 30 requests came B comes. The whole trouble is that we can not create infinitely many php processes and the way to increase them in exorbitant quantities is incorrect.
The most important thing that should be taken out of these schemes is that the operations of working with the database in php are performed synchronously. In our case, the process that performed the query to the database is unable to process other requests and is forced to “hang” (without doing anything) expecting a response from the database.
What does nodejs give us?
First, let's see how a simple server looks like:
Immediately striking is the fact that the server includes the processors of requests A and B directly, as well as the Web server itself. All this stuff turns in one node process and constantly hangs in memory.
Let's look at the scheme of work:
The diagram clearly shows that requests B do not cause the server to “hang” while waiting for the base to respond. The server receiving the request B, simply generates and sends the request to the database, and will continue to respond to other requests, as soon as the response from the database is received, the server will return the result to the client. In the case of nodejs, it doesn’t matter how or how many B requests come in, none of them will lead to “hanging” waiting for the base to respond.
And the conclusion is simple.
Having come to nodejs do not try to do something the way you did in php.
Remember that you are working in an asynchronous environment, do not use blocking operations, you are killing the idea of ​​nodejs.
Remember that nodejs handles many requests in one process that are constantly hanging in memory, so watch your variables and how you use memory.
You should not run 50 node processes for one site, and generally you should not run them more than the number of cores on the processor, more of them only slow down the work as a whole.
A nodejs is not a silver bullet and its use alone will not solve the problems of scaling and work under heavy loads.
It is always better to explain something by a clear example with pictures. Therefore, let's invent a small “spherical site in a vacuum” and accept some conditions.
Suppose we have a site that understands only two requests:
Request A is executed in 1 second, it does not require access to the database.
Request B is executed in 5 seconds, and 4 of them, it spends waiting for the response of the database.
We also agree that the time between requests is at least 1 second.
Php
Let's take a look at how this works on php.
In its most simplified form, the server architecture looks like this:
')
The following is important here, the web server receiving a request from the client sends it to the php process. In turn, the php process can process one request at a time, upon completion of the work, the result is returned to the web server, and the process itself ceases to exist. The web server receiving the response sends the result to the client and closes the connection.
If there is only one php process, the work of our server can be displayed on this scheme:
It is clear from the diagram that as long as only requests come to us, our server responds to them vigorously and generally performs its tasks, but as soon as request B comes to us, the server stops responding to requests until the answer to request B is ready. Also on the diagram you can see that most of the time query B, “everyone” waits for the result of the database operation.
To solve this problem, we have to increase the number of php processes, let's increase to 2x, as a result, the scheme takes the following form:
From this scheme, it is clear that request B “hangs” in processing in the first php process, while the server continues to respond to other requests. Everything will go well until the moment when two requests B come to us, then both php processes will “hang” waiting for the base to respond, and the server as a whole will stop responding until one of them is free.
Well, we already know what to do? That's right, let's take and increase the number of php processes, immediately to 20 or 30 and the problem seems to be gone, although in fact the problem just drifted away a bit and the moment when 30 requests came B comes. The whole trouble is that we can not create infinitely many php processes and the way to increase them in exorbitant quantities is incorrect.
The most important thing that should be taken out of these schemes is that the operations of working with the database in php are performed synchronously. In our case, the process that performed the query to the database is unable to process other requests and is forced to “hang” (without doing anything) expecting a response from the database.
nodejs
What does nodejs give us?
First, let's see how a simple server looks like:
Immediately striking is the fact that the server includes the processors of requests A and B directly, as well as the Web server itself. All this stuff turns in one node process and constantly hangs in memory.
Let's look at the scheme of work:
The diagram clearly shows that requests B do not cause the server to “hang” while waiting for the base to respond. The server receiving the request B, simply generates and sends the request to the database, and will continue to respond to other requests, as soon as the response from the database is received, the server will return the result to the client. In the case of nodejs, it doesn’t matter how or how many B requests come in, none of them will lead to “hanging” waiting for the base to respond.
Conclusion
And the conclusion is simple.
Having come to nodejs do not try to do something the way you did in php.
Remember that you are working in an asynchronous environment, do not use blocking operations, you are killing the idea of ​​nodejs.
Remember that nodejs handles many requests in one process that are constantly hanging in memory, so watch your variables and how you use memory.
You should not run 50 node processes for one site, and generally you should not run them more than the number of cores on the processor, more of them only slow down the work as a whole.
A nodejs is not a silver bullet and its use alone will not solve the problems of scaling and work under heavy loads.
Source: https://habr.com/ru/post/140066/
All Articles