Italian Translation Report: Node.js [Part 39 - 1136 words]

Oct 6th, 2018
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. A single instance of Node.js runs in a single thread.
  2. To take advantage of multi-core systems, the user will sometimes want to launch a cluster of Node.js processes to handle the load.
  3. The cluster module allows easy creation of child processes that all share server ports.
  4. Fork workers.
  5. Workers can share any TCP connection
  6. In this case it is an HTTP server
  7. Running Node.js will now share port 8000 between the workers:
  8. Please note that on Windows, it is not yet possible to set up a named pipe server in a worker.
  9. How It Works
  10. The worker processes are spawned using the method, so that they can communicate with the parent via IPC and pass server handles back and forth.
  11. The cluster module supports two methods of distributing incoming connections.
  12. The first one (and the default one on all platforms except Windows), is the round-robin approach, where the master process listens on a port, accepts new connections and distributes them across the workers in a round-robin fashion, with some built-in smarts to avoid overloading a worker process.
  13. The second approach is where the master process creates the listen socket and sends it to interested workers. The workers then accept incoming connections directly.
  14. The second approach should, in theory, give the best performance. In practice however, distribution tends to be very unbalanced due to operating system scheduler vagaries. Loads have been observed where over 70% of all connections ended up in just two processes, out of a total of eight.
  15. Because hands off most of the work to the master process, there are three cases where the behavior between a normal Node.js process and a cluster worker differs:
  16. Because the message is passed to the master, file descriptor 7 in the parent will be listened on, and the handle passed to the worker, rather than listening to the worker's idea of what the number 7 file descriptor references.
  17. Listening on handles explicitly will cause the worker to use the supplied handle, rather than talk to the master process.
  18. Normally, this will cause servers to listen on a random port. However, in a cluster, each worker will receive the same "random" port each time they do. In essence, the port is random the first time, but predictable thereafter. To listen on a unique port, generate a port number based on the cluster worker ID.
  19. Node.js does not provide routing logic. It is, therefore important to design an application such that it does not rely too heavily on in-memory data objects for things like sessions and login.
  20. Because workers are all separate processes, they can be killed or re-spawned depending on a program's needs, without affecting other workers. As long as there are some workers still alive, the server will continue to accept connections. If no workers are alive, existing connections will be dropped and new connections will be refused. Node.js does not automatically manage the number of workers, however. It is the application's responsibility to manage the worker pool based on its own needs.
  21. Although a primary use case for the cluster module is networking, it can also be used for other use cases requiring worker processes.
  22. A object contains all public information and method about a worker.
  23. In the master it can be obtained using
  24. In a worker it can be obtained using
  25. Similar to the event, but specific to this worker.
  26. Worker has disconnected
  27. This event is the same as the one provided by
  28. Within a worker, may also be used
  29. The exit code, if it exited normally.
  30. The name of the signal (e.g.) that caused the process to be killed.
  31. It is not emitted in the worker.
  32. As an example, here is a cluster that keeps count of the number of requests in the master process using the message system:
  33. Keep track of http requests
  34. Count requests
  35. Start workers and listen for messages containing
  36. Worker processes have a http server.
  37. notify master about the request
  38. Worker is online
  39. Returns: A reference to
  40. In a worker, this function will close all servers, wait for the event on those servers, and then disconnect the IPC channel.
  41. In the master, an internal message is sent to the worker causing it to call on itself.
  42. Causes to be set.
  43. Note that after a server is closed, it will no longer accept new connections, but connections may be accepted by any other listening worker. Existing connections will be allowed to close as usual. When no more connections exist, see, the IPC channel to the worker will close allowing it to die gracefully.
  44. The above applies only to server connections, client connections are not automatically closed by workers, and disconnect does not wait for them to close before exiting.
  45. Note that in a worker, exists, but it is not this function, it is
  46. Because long living server connections may block workers from disconnecting, it may be useful to send a message, so application specific actions may be taken to close them. It also may be useful to implement a timeout, killing a worker if the event has not been emitted after some time.
  47. connections never end
  48. initiate graceful close of any connections to server
  49. Set by calling or
  50. Until then, it is
  51. The boolean allows distinguishing between voluntary and accidental exit, the master may choose not to respawn a worker based on this value.
  52. kill worker
  53. Each new worker is given its own unique id, this id is stored in the
  54. While a worker is alive, this is the key that indexes it in
  55. This function returns if the worker is connected to its master via its IPC channel, otherwise. A worker is connected to its master after it has been created. It is disconnected after the event is emitted.
  56. This function returns if the worker's process has terminated (either because of exiting or being signaled). Otherwise, it returns
  57. Name of the kill signal to send to the worker process.
  58. This function will kill the worker.
  59. In the master, it does this by disconnecting the, and once disconnected, killing with
  60. In the worker, it does it by disconnecting the channel, and then exiting with code
  61. Causes to be set.
  62. This method is aliased as for backwards compatibility.
  63. Note that in a worker, exists, but it is not this function, it is
  64. All workers are created using, the returned object from this function is stored as
  65. In a worker, the global is stored.
  66. Note that workers will call if the event occurs on and is not
  67. This protects against accidental disconnection.
  68. Send a message to a worker or master, optionally with a handle.
  69. In the master this sends a message to a specific worker. It is identical to
  70. In a worker this sends a message to the master. It is identical to
  71. This example will echo back all messages from the master:
RAW Paste Data

Adblocker detected! Please consider disabling it...

We've detected AdBlock Plus or some other adblocking software preventing from fully loading.

We don't have any obnoxious sound, or popup ads, we actively block these annoying types of ads!

Please add to your ad blocker whitelist or disable your adblocking software.