미래 지향적인 웹 앱 구축: The Codest의 전문가 팀이 제공하는 인사이트
The Codest가 최첨단 기술로 확장 가능한 대화형 웹 애플리케이션을 제작하고 모든 플랫폼에서 원활한 사용자 경험을 제공하는 데 탁월한 성능을 발휘하는 방법을 알아보세요. Adobe의 전문성이 어떻게 디지털 혁신과 비즈니스를 촉진하는지 알아보세요...
“Don`t block the event loop…” – you’ve probably heard this sentence many times… I’m not surprised because it is one of the most important assumptions when working with Node. But there is also a second “thing” which you should refrain from blocking – the Worker Pool. If neglected, it can have a significant impact on application performance and even its security.
Main thing to remember: there are two types of threads in Node.js: Main Thread – which is handled by Event Loop및 Worker Pool (thread pool) – which is the pool of threads –
thanks to libuv. Each of them has a different job. The goal of the first one is to handle non-blocking I/O operations, and the second is responsible for CPU intensive work and also blocking I/O.
But what is a thread and how it’s different than a process? There are several differences, but the most important one for us is how the memory is allocated to them. You can think about a process like about an application. Inside each process, there is a chunk of memory dedicated just for this process. So, one process doesn`t have access to the memory of the second one, and this property ensures high security. To establish communication between them, we must do some work. Threads are different. Threads runs inside a process and share the same memory so there is no problem at all with threads sharing data.
However, one issue causes a problem. It’s called the race condition. The threads can run at the same time, so how do we know which ends first? It may happen that the first time you run it, the first operation ends first, and next time it may turn out to be the opposite and the second operation ends before the first one. Imagine working with write/read operations under such conditions! A nightmare! It’s sometimes very hard to write correct 코드 in a multi-threaded environment.
Also, the multi-threaded languages have a large memory overhead because they create a separate thread for each request; so, if you want to call 1000 requests, they create 1000 threads.
How to deal with such a problem? Use a single thread instead! And that is what 노드 offers you.
로서 JavaScript 개발자 I encourage you to watch the movie
in which Bart Belder clearly explains the concept of the event loop. The above diagram is taken from his presentation. And if you don’t know these terms at all, both 노드 and Libuv have excellent documentation 🙂
In JavaScript 개발 industry they say that because 노드 is single-threaded and non-blocking, you can achieve higher concurrency with the same resources than with multi-threaded solutions. It`s true but it is not as beautiful and easy as it may seem.
이후 Node.js is single-threaded (JS part), CPU-intensive tasks will block all requests in progress until the particular task is completed. So, it`s true that in Node.js you can block every request just because one of them had a blocking instruction inside. The blocking code means that it takes more that few milliseconds to finish. But do not confuse long response time with blocking. The response from database can take a very long time, but it does not block your process (application).
Blocking methods execute synchronously and non-blocking methods execute asynchronously.
How can you slow down (or block) your event loop?
In that case, since the Worker Pool uses a pool of threads, is it possible to block them too? Unfortunately, yes 🙁 노드 is based on a philosophy one thread for many clients.
Let’s assume that a given task performed by a specific Worker is very complex and needs more time to be finished. As a result, the Worker is blocked and it can’t be used to execute any of the other pending tasks until its instructions are executed. As you have probably guessed by now, it may affect the performance. You can prevent such issues by minimizing the variation in Task times by using Task partitioning.
Avoid blocking, that’s for sure. If you only can, always choose asynchronous versions of the standard library APIs. Otherwise, after running your app, the client can experience several problems, starting with the degraded throughput and ending on complete withdrawal, which is fatal from the user’s perspective.
자세히 읽어보세요: