@Evila
There are JAVA, PHP, .NET, PYTHON, etc. for making websites. What are the advantages of node.js and them?
I didn't understand the advantages of NODE.JS. For example, node.js reads HTML template files, and php also reads template files, so the frequency of IO operations is equal. If it is a service, such as using socket.io as a socket server, PHP can also do it.
I also can't understand, what can NODE.JS do, what PHP/.NET/JAVA can't do? Don't talk about the NODE.JS module, you can use C++ to develop modules for node.js, and you can also use c/c# to develop the underlying stuff for PHP/ASP.NET.
@杨金华:
According to node.js: Simple logic processing and high concurrent requests can only use node.js. Complex page logic, cannot use node.js, event-driven: node.js receives a request and binds an event immediately, such as request.bind('succ', function(){ print 'respond to the customer';} ) ; That is, like ajax, it responds to the client asynchronously, but this process happens on the server side.
High traffic and simple logic: do output such as print 'hello world', it may involve reading output from the database, and node.js cannot be used..
Hehe, with node.js like this, it may be difficult to promote applications.
@红星XX:
Such as webserver application, a large number of requests are sent to the webserver server, nginx, apache can't handle it
At this time, the power of node.js came out. The load of a server was ten times higher than before.
Especially suitable for the following scenarios:
RESTful API
A web service that provides a RESTful API accepts several parameters, parses them, assembles a response, and returns a response (usually less text) to the user. This is an ideal situation for Node because you can build it to handle tens of thousands of connections. It still doesn't require a lot of logic; it essentially just looks up some values from some database and composes them into a response. Since the response is a small amount of text, and the inbound request is also a small amount of text, traffic is not high and one machine can handle the API demands of even the busiest companies.
Twitter queue
Imagine a company like Twitter that has to receive tweets and write them to a database. In practice, with almost thousands of tweets arriving every second, it is impossible for the database to handle the number of writes required during peak hours in a timely manner. Node became an important part of the solution to this problem. As you can see, Node can handle tens of thousands of incoming tweets. It can quickly and easily write them to an in-memory queuing mechanism (such as memcached), from where a separate process can write them to the database. Node's role here is to quickly collect tweets and pass this information to another process responsible for writing. Imagine another design (regular PHP server would try to handle the write to the database itself): each tweet would cause a short delay in writing to the database because the database call was blocking the channel. A machine designed this way might only be able to handle 2000 inbound tweets per second due to database latency. Processing 1 million tweets per second requires 500 servers. Instead, Node handles each connection without blocking the channel, thus capturing as many tweets as possible. A Node machine that can handle 50,000 tweets only needs 20 servers.
Video Game Statistics
If you've played the game Call of Duty online, when you look at game stats, you'll immediately realize a problem: To generate that level of stats, you have to track a ton of information. In this way, if there are millions of players playing online at the same time, and they are in different positions in the game, a huge amount of information can be generated very quickly. Node is a good solution for this scenario, as it ingests game-generated data, does minimal merging of the data, and then queues the data so that it can be written to the database. Using an entire server to track how many bullets a player has fired in a game seems silly, and if you're using a server like Apache, there may be some useful limitations; but instead, if you're using one server specifically to track all of a game's stats data, as you would do with a server running Node, that seems like a no-brainer.
@YinJersey:
You want to know why he is good? Let me tell you so. There are several considerations in the performance of the web service system, the number of 1 connections. 2. Background business. The background business includes business logic and data storage. There are many software on the market that test the number of concurrent connections. I don't know if you have used it. Things like iis and jboss have a limit on the number of concurrent connections. The reason is that when a web server establishes one connection, one process is opened, and each process requires about a few MB of basic memory, so the number of connections that the web server can open is not determined by the web server memory. And nodejs opens a process, driven by events, that is a repeater, connector, other business logic and data storage, that is the problem of the local machine. You are right in saying that performance optimization can be optimized anywhere. The database can be optimized, the business logic can be optimized. But where are the system bottlenecks in general? Just like China's booking system, it is the web server, and the number of concurrent connections to the old web server is limited. Therefore, the number of people in the Chinese booking system is slow, and the reason for the slowness is not that the background business processing and database are slow. People from this or that company that does the booking system have already said that the slow system is not a problem of data connection in the computer room. In fact, what they mean is that there is a problem with the number of web server connections. Should try nodejs. As for RESTful, it's an architectural style that other software can support, not its specific. His specificity is a single process, asynchronous communication. Anyone who engages in it understands that asynchronous communication is much faster than synchronous communication.