The discussion centered around the following question: If we have a separate microservice that handles longer running requests and it's okay for all requests of that type to be handled sequentially, can we just run those on the main thread loop? Sometimes, you need to do computation that will take a while to complete, and you cannot break up that work. The team had a very interesting discussion around longer-running requests. Worker threads are also likely appropriate for desktop-type applications where it is known that you cannot scale beyond the resources of a single machine, and it is preferable to have the application show up as a single process instead of many individual processes. If that is not possible, then worker threads are the recommended approach versus multiple processes running in a single container as there will be lower complexity and less overhead communicating between multiple threads of execution. The team's experience is that, when possible, applications should be designed so that a request to a microservice running in a container will need no more than a single thread of execution to complete in a reasonable time. How to balance this work across threads, processes, and computers and scale it in times of increased demand is an important topic for most deployments. The reality is that applications based on Node.js can and do leverage multiple threads of execution over one or more computers. In addition, Node.js applications are often made up of multiple different microservices and multiple copies of each microservice, allowing the overall solution to leverage many concurrent threads available in a single computer or across a group of computers. While by default a Node.js process operates in a single-threaded model, current versions of Node.js support worker threads that you can use to start additional threads of execution, each with their own event loop. If that is the case, then why are we even talking about threading? The asynchronous nature of JavaScript means that Node.js can handle a larger number of concurrent requests on that single thread. While not entirely true, it reflects that most work is done on a single thread running the event loop. Part 16: Load balancing, threading, and scaling. Part 1: Overview of the Node.js reference architecture.This installment of the ongoing Node.js reference architecture series covers the team's experience on how to satisfy the need for larger computational resources in your Node.js application. Many applications require more computation than can be handled by a single thread, CPU, process, or machine.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |