<div id="readability-page-1" class="page"><cite>나를찾는아이</cite>
 2022. 8. 8. 12:48
 <div>
 <a href="https://nodejs.org/en/docs/guides/dont-block-the-event-loop/" target="_blank" rel="noopener">https://nodejs.org/en/docs/guides/dont-block-the-event-loop/</a>
<figure id="og_1659922922506" contenteditable="false" data-ke-type="opengraph" data-ke-align="alignCenter" data-og-type="website" data-og-title="Don't Block the Event Loop (or the Worker Pool) | Node.js" data-og-description="Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine." data-og-host="nodejs.org" data-og-source-url="https://nodejs.org/en/docs/guides/dont-block-the-event-loop/" data-og-url="https://nodejs.org/en/docs/guides/dont-block-the-event-loop/" data-og-image="https://scrap.kakaocdn.net/dn/ALdAQ/hyPl9MZHDe/yUhV2JUpU5K20gIrJkDLy0/img.png?width=224&amp;height=256&amp;face=0_0_224_256,https://scrap.kakaocdn.net/dn/jmxzf/hyPl7Itx6J/2j9aAIHiEJNLC9sYZ8iJwK/img.png?width=224&amp;height=256&amp;face=0_0_224_256"><a href="https://nodejs.org/en/docs/guides/dont-block-the-event-loop/" target="_blank" rel="noopener" data-source-url="https://nodejs.org/en/docs/guides/dont-block-the-event-loop/">

<div>
Don't Block the Event Loop (or the Worker Pool) | Node.js
Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.
nodejs.org
</div>
</a><img src="https://scrap.kakaocdn.net/dn/ALdAQ/hyPl9MZHDe/yUhV2JUpU5K20gIrJkDLy0/img.png?width=224&amp;height=256&amp;face=0_0_224_256,https://scrap.kakaocdn.net/dn/jmxzf/hyPl7Itx6J/2j9aAIHiEJNLC9sYZ8iJwK/img.png?width=224&amp;height=256&amp;face=0_0_224_256"></figure>

nodejs는 non blocking 이벤트 루프 형태의 시스템을 가지고 있습니다

이런 nodejs의 장점을 살리기 위해서는 메인 이벤트 루프를 blocking 하는 것을 가급적이면 최소화하는것이 시스템의 최고 효율을 낼수 있습니다

메인이벤트루프를 blocking 하는 작업을 실행하면 다른 요청이 들어왔을때 blocking된 작업을 완전히 처리하고 난 뒤에 다음 이벤트가 처리될수 있기때문에 전체적인 시스템의 성능이 저하됩니다

메인 이벤트 루프가 단일쓰레드라 nodejs가 싱글스레드라고 단순히 인식하기 쉬운데요

메인 이벤트 루프는 싱글스레드로 동작하지만,

nodejs는 비싼 작업을 위해 워커 사용하는데 이 워커는 쓰레드풀을 활용합니다


워커를 사용하는 값비싼 작업은 다음과 같습니다

I/O-intensive DNS:&nbsp;dns.lookup(),&nbsp;dns.lookupService(). File&nbsp;System:&nbsp;All&nbsp;file&nbsp;system&nbsp;APIs&nbsp;except&nbsp;fs.FSWatcher()&nbsp;and&nbsp;those&nbsp;that&nbsp;are&nbsp;explicitly&nbsp;synchronous&nbsp;use&nbsp;libuv's&nbsp;threadpool. CPU-intensive Crypto:&nbsp;crypto.pbkdf2(),&nbsp;crypto.scrypt(),&nbsp;crypto.randomBytes(),&nbsp;crypto.randomFill(),&nbsp;crypto.generateKeyPair(). Zlib:&nbsp;All&nbsp;zlib&nbsp;APIs&nbsp;except&nbsp;those&nbsp;that&nbsp;are&nbsp;explicitly&nbsp;synchronous&nbsp;use&nbsp;libuv's&nbsp;threadpool.


그렇기 때문에 위에서 언급된 i/o, cpu intensive한 작업이 있는 서비스를 운영할 경우에는

쓰레드풀의 크기를 늘려 워커를 늘리는것은 서비스의 전체적인 퍼포먼스 향상에 도움을 줍니다


한번 테스트 해볼까요

제 맥북(맥북프로 m1)에서 테스트를 실행해보겠습니다

<pre id="code_1659923925811" data-ke-language="javascript" data-ke-type="codeblock"><code>const crypto = require("crypto");

console.time("thread");

for (let i = 1; i &lt;= 16; i++) {
 console.time(`pbkdf2:${i}`);
 crypto.pbkdf2("password", "salt", 100000, 512, "sha512", () =&gt; {
 console.timeEnd(`pbkdf2:${i}`);
 });
}

console.timeEnd("thread");</code></pre>

값비싼 예제로 언급되었던 crypto.pbkdf2를 사용하여 암호화를 하는 작업을 해보겠습니다

이작업은 1번의 작업만 했을때 약 400ms의 시간이 소요되는 작업입니다

16번의 pdkdf2 작업을 하는 프로그램을 작성해보았습니다

시작시간과 종료시간을 체크하여 각각의 작업이 언제 끝나는지 확인해보죠


싱글쓰레드의 nodejs를 생각하면 언듯 생각했을때는

1번작업이 끝나면 2번작업이 시작되고 2번작업이 끝나면 3번작업이 시작되는 그런 모습을 생각하셨을수 있습니다

그래서 16개의 모든 암호화 작업이 끝나는 시간이 최종적으로&nbsp;

약 400ms X 16개 = 약 6.4초

이렇게 될것으로 예상하는데요


프로그램을 실행해보겠습니다


<figure data-ke-mobilestyle="widthOrigin" data-filename="스크린샷 2022-08-08 오전 10.38.28.png" data-origin-width="544" data-origin-height="510">
 
 <img src="https://k.kakaocdn.net/dn/bXyLKU/btrI9mZ0Lts/SzMkjM1eaOahxteAT5QxK0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="스크린샷 2022-08-08 오전 10.38.28.png" data-origin-width="544" data-origin-height="510">
 
 
</figure>

4개단위씩 묶어서 숫자가 400ms씩 증가하는것을 볼수 있습니다

4개 단위안에서는 종료시간의 차이가 거의 없습니다

왜 4개씩 차이가 나는걸까요?

이는 4개의 워커가 동작하고 있어서 순차적으로 들어온 작업을 4개의 워커가 나눠서 작업을 했기 때문에

4개의 워커가 작업이 끝나고 다음 4개가 작업이 착수가 된것이라고 볼수 있습니다

<figure data-ke-mobilestyle="widthOrigin" data-filename="스크린샷 2022-08-08 오전 11.36.46.png" data-origin-width="1232" data-origin-height="1378">
 
 <img src="https://k.kakaocdn.net/dn/ppnpq/btrI7LZ6s7m/Bsgzjo8hmnBixFZZ8QP8z0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="스크린샷 2022-08-08 오전 11.36.46.png" data-origin-width="1232" data-origin-height="1378">
 
 
</figure>

이런식의 느낌으로 말이죠


그렇다면 워커의 갯수는 어떻게 늘릴수 있을까요?

UV_THREADPOOL_SIZE 를 프로그램이 실행되기 직전에 선언해줍니다

<pre id="code_1659924152247" data-ke-language="javascript" data-ke-type="codeblock"><code>UV_THREADPOOL_SIZE=8 node index.js</code></pre>

<figure data-ke-mobilestyle="widthOrigin" data-filename="스크린샷 2022-08-08 오전 10.39.24.png" data-origin-width="728" data-origin-height="518">
 
 <img src="https://k.kakaocdn.net/dn/bpUWAu/btrI6sfnACG/8cuEwxBKVVBL9sMimrJr01/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="스크린샷 2022-08-08 오전 10.39.24.png" data-origin-width="728" data-origin-height="518">
 
 
</figure>


쓰레드를 8개로 늘렸더니 8개 작업마다 시간이 400ms 증가했습니다


그렇다면 1개로 변경해보고 실행해보죠

<pre id="code_1659924162414" data-ke-language="javascript" data-ke-type="codeblock"><code>UV_THREADPOOL_SIZE=1 node index.js</code></pre>

<figure data-ke-mobilestyle="widthOrigin" data-filename="스크린샷 2022-08-08 오전 10.39.06.png" data-origin-width="722" data-origin-height="504">
 
 <img src="https://k.kakaocdn.net/dn/dwj5pA/btrJcFrhABI/7mc2ZJiRkuzYViL0J5vpd0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="스크린샷 2022-08-08 오전 10.39.06.png" data-origin-width="722" data-origin-height="504">
 
 
</figure>
최초에 우리가 생각했던 그러한 시간의 모습이 나왔습니다

약 400ms씩 증가하여 하나씩 순차적으로 완료가 되고 있습니다


<figure data-ke-mobilestyle="widthOrigin" data-filename="스크린샷 2022-08-08 오전 11.38.00.png" data-origin-width="2576" data-origin-height="610">
 
 <img src="https://k.kakaocdn.net/dn/oGfru/btrJaWNBU2Y/nm0maH5rGHXsdoYTDGZ8Q0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="스크린샷 2022-08-08 오전 11.38.00.png" data-origin-width="2576" data-origin-height="610">
 
 
</figure>
그림으로 보자면 이런 느낌이겠죠



이렇듯 nodejs는 쓰레드풀을 사용하여 워커를 사용하고 있습니다

<a href="http://docs.libuv.org/en/v1.x/threadpool.html" target="_blank" rel="noopener">http://docs.libuv.org/en/v1.x/threadpool.html</a>
<figure id="og_1659924661700" contenteditable="false" data-ke-type="opengraph" data-ke-align="alignCenter" data-og-type="website" data-og-title="Thread pool work scheduling — libuv documentation" data-og-description="Thread pool work scheduling libuv provides a threadpool which can be used to run user code and get notified in the loop thread. This thread pool is internally used to run all file system operations, as well as getaddrinfo and getnameinfo requests. Its defa" data-og-host="docs.libuv.org" data-og-source-url="http://docs.libuv.org/en/v1.x/threadpool.html" data-og-url="http://docs.libuv.org/en/v1.x/threadpool.html" data-og-image=""><a href="http://docs.libuv.org/en/v1.x/threadpool.html" target="_blank" rel="noopener" data-source-url="http://docs.libuv.org/en/v1.x/threadpool.html">

<div>
Thread pool work scheduling — libuv documentation
Thread pool work scheduling libuv provides a threadpool which can be used to run user code and get notified in the loop thread. This thread pool is internally used to run all file system operations, as well as getaddrinfo and getnameinfo requests. Its defa
docs.libuv.org
</div>
</a></figure>

기본사이즈는 4고 UV_THREADPOOL_SIZE 환경변수를 세팅하여 최대 1024개까지 설정이 가능합니다
(Changed in version 1.30.0: the maximum UV_THREADPOOL_SIZE allowed was increased from 128 to 1024.)












 
 
 </div></div>

나를 찾는 아이

Kyoung min, Kim

https://nodejs.org/en/docs/guides/dont-block-the-event-loop/
 
nodejs는 non blocking 이벤트 루프 형태의 시스템을 가지고 있습니다
 
이런 nodejs의 장점을 살리기 위해서는 메인 이벤트 루프를 blocking 하는 것을 가급적이면 최소화하는것이 시스템의 최고 효율을 낼수 있습니다
 
메인이벤트루프를 blocking 하는 작업을 실행하면 다른 요청이 들어왔을때 blocking된 작업을 완전히 처리하고 난 뒤에 다음 이벤트가 처리될수 있기때문에 전체적인 시스템의 성능이 저하됩니다
 
메인 이벤트 루프가 단일쓰레드라 nodejs가 싱글스레드라고 단순히 인식하기 쉬운데요
 
메인 이벤트 루프는 싱글스레드로 동작하지만,
 
nodejs는 비싼 작업을 위해 워커 사용하는데 이 워커는 쓰레드풀을 활용합니다
 
 
워커를 사용하는 값비싼 작업은 다음과 같습니다
 
I/O-intensive
DNS: dns.lookup(), dns.lookupService().
File System: All file system APIs except fs.FSWatcher() and those that are explicitly synchronous use libuv's threadpool.
CPU-intensive
Crypto: crypto.pbkdf2(), crypto.scrypt(), crypto.randomBytes(), crypto.randomFill(), crypto.generateKeyPair().
Zlib: All zlib APIs except those that are explicitly synchronous use libuv's threadpool.
 
 
그렇기 때문에 위에서 언급된 i/o, cpu intensive한 작업이 있는 서비스를 운영할 경우에는
 
쓰레드풀의 크기를 늘려 워커를 늘리는것은 서비스의 전체적인 퍼포먼스 향상에 도움을 줍니다
 
 
한번 테스트 해볼까요
 
제 맥북(맥북프로 m1)에서 테스트를 실행해보겠습니다
 
const crypto = require("crypto");
console.time("thread");
for (let i = 1; i <= 16; i++) {
 console.time(`pbkdf2:${i}`);
 crypto.pbkdf2("password", "salt", 100000, 512, "sha512", () => {
 console.timeEnd(`pbkdf2:${i}`);
 });
}
console.timeEnd("thread");
 
값비싼 예제로 언급되었던 crypto.pbkdf2를 사용하여 암호화를 하는 작업을 해보겠습니다
 
이작업은 1번의 작업만 했을때 약 400ms의 시간이 소요되는 작업입니다
 
16번의 pdkdf2 작업을 하는 프로그램을 작성해보았습니다
 
시작시간과 종료시간을 체크하여 각각의 작업이 언제 끝나는지 확인해보죠
 
 
싱글쓰레드의 nodejs를 생각하면 언듯 생각했을때는
 
1번작업이 끝나면 2번작업이 시작되고 2번작업이 끝나면 3번작업이 시작되는 그런 모습을 생각하셨을수 있습니다
 
그래서 16개의 모든 암호화 작업이 끝나는 시간이 최종적으로 
 
약 400ms X 16개 = 약 6.4초
 
이렇게 될것으로 예상하는데요
 
 
프로그램을 실행해보겠습니다
 
 
 
4개단위씩 묶어서 숫자가 400ms씩 증가하는것을 볼수 있습니다
 
4개 단위안에서는 종료시간의 차이가 거의 없습니다
 
왜 4개씩 차이가 나는걸까요?
 
이는 4개의 워커가 동작하고 있어서 순차적으로 들어온 작업을 4개의 워커가 나눠서 작업을 했기 때문에
 
4개의 워커가 작업이 끝나고 다음 4개가 작업이 착수가 된것이라고 볼수 있습니다
 
 
이런식의 느낌으로 말이죠
 
 
그렇다면 워커의 갯수는 어떻게 늘릴수 있을까요?
 
UV_THREADPOOL_SIZE 를 프로그램이 실행되기 직전에 선언해줍니다
 
UV_THREADPOOL_SIZE=8 node index.js
 
 
 
쓰레드를 8개로 늘렸더니 8개 작업마다 시간이 400ms 증가했습니다
 
 
그렇다면 1개로 변경해보고 실행해보죠
 
UV_THREADPOOL_SIZE=1 node index.js
 
최초에 우리가 생각했던 그러한 시간의 모습이 나왔습니다
 
약 400ms씩 증가하여 하나씩 순차적으로 완료가 되고 있습니다
 
 
그림으로 보자면 이런 느낌이겠죠
 
 
 
이렇듯 nodejs는 쓰레드풀을 사용하여 워커를 사용하고 있습니다
 
http://docs.libuv.org/en/v1.x/threadpool.html
 
기본사이즈는 4고 UV_THREADPOOL_SIZE 환경변수를 세팅하여 최대 1024개까지 설정이 가능합니다
(Changed in version 1.30.0: the maximum UV_THREADPOOL_SIZE allowed was increased from 128 to 1024.)

nodejs 쓰레드 활용하기

댓글