md` # Web Worker를 이용한 Fetch 벤치마킹 - [sungryeolp@gmail.com](mailto:sungryeolp@gmail.com) ## 이유 웹에서 대부분의 병목현상은 통신에서 발생합니다. 특히 앱의 크기가 커질수록 여러개의 분산된 엔드포인트에서 자료를 가져오게 되는 경우가 많습니다. 여러개의 요청을 시도하게 될 경우, 지연이 중첩되어 더욱 큰 지연현상이 발생하게 됩니다. 따라서 \`Promise.all\`을 이용해 하나의 통신이 다른 통신에 영향을 주지 않도록 하는 방법을 고려하는 경우가 흔합니다. 걸리는 시간을 비교하면 아래와 같이 될 것으로 추측할 수 있습니다. \`\`\` for await (하나의 요청 in 여러개의 요청) {} > await Promise.all(여러개의 요청) \`\`\` **문제는 자바스크립트가 본질적으로 싱글 스레드 기반**이라는 것입니다. 따라서 여러개의 요청을 거의 동시에 발생시키더라도, 하나의 요청이 전부 수행되기 이전에 다른 요청이 수행되어 다른 요청에 영향을 주게 됩니다.

통신 요청을 보내고 대기하는 상황만 발생한다면 지연이 발생할리 없습니다. 하지만 보통 하나의 통신 요청은 값을 집어넣거나 파싱하는 등, 연산을 함께 수행해야 합니다. 하나의 통신 요청을 처리하는 과정이 완료되기 직전에 다른 요청을 처리해야하는 상황이 발생하면 자연스럽게 싱글 스레드는 두 가지 일을 동시에 처리해야하는 상황에 됩니다. 따라서 [web worker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers)사용을 고려해볼 수 있습니다. web worker는 자연스럽게 특정 function을 멀티쓰레드로 처리해줍니다. 이론적으로 멀티쓰레드를 사용하는 web worker가 싱글 스레드 기반의 병렬처리보다 빠르다고 누구나 예상할 수 있습니다. 그러나 중요한 것은 **얼마나 빠른가** 입니다. 웹은 애자일한 개발도 무척 중요하기 때문에, micro-optimization이라면 안하느니만 못할 수 있습니다. 따라서 테스트를 만들어 병렬로 web worker를 사용한 요청과 web worker를 사용하지 않은 일반적인 요청을 처리하는데 걸리는 시간을 비교해 보았습니다. 테스트는 반드시 \`Promise.all()\`을 통하여 묶음으로 진행됩니다. 개별 요청 처리 시간은 마킹하지 않습니다. 이론상 병목현상은 여러개의 요청이 싱글스레드에서 동시에 진행될 때에만 발생되기 때문입니다.

처음 테스트를 만들고 진행했을 때, 예상하지 못한 이상치들이 발견되었습니다. 이유는 여러가지일 수 있습니다. 잦은 통신 요청으로 목표 url에서 쓰로틀링을 걸었을 수도 있고, 이전 테스트 내역이 heap메모리에 쌓이면서 퍼포먼스에 영향을 주고 있는 것일수도 있습니다. 따라서 이상치들을 제외하기 위해 표준편차값을 구하여 2표준편차만 사용한 비교 메시지를 차트 하단에 아래와 같이 표기합니다. \`\`\` 요청 ***가 2표준편차 기준으로 *배 느립니다. \`\`\` - \`다운로드 및 벤치마킹\` 버튼을 클릭하면 샘플링을 ${sampling} × ${sampleTry} 회 실시합니다. - 테스트 시도를 여러번 할 경우, 다운로드 결과는 누적됩니다. - 목표 서버에 지나치게 부하를 주지 않도록, 하나의 샘플링간 약간의 시간차를 두고 연속으로 테스트하며, 테스트 버튼을 누르기 전까지 테스트는 진행되지 않습니다. - 아래의 코드를 수정하여 목표 서버나 테스트 내용을 변경할 수 있습니다. `

Purpose-built for displays of data