웹 워커에 도전 한 이유
어느 정도 기능들이 완성되고 난 후, 테스팅 하는 도중 브라우저의 동작이 자주 멈추었다...
처음에는 좌석의 수가 10000개 이므로 캔버스 그리는 동작이 오래 걸린다고 생각을 했었다 그래서 캔버스 동작을 개선하기 위해 노력을 했지만 상황은 나아지지 않았다.
문제를 파악하기 위해 google 개발자 도구를 performance 측정을 해봤다.
좌석 4개를 연속하여 클릭 하기 까지의 퍼포먼스를 측정해봤는데
생각을 하지 않았던 웹소켓 모듈에서 오랜 시간이 걸리는 것을 확인 할 수 있었다. https://developer.mozilla.org/ko/docs/WebSockets/Writing_WebSocket_servers#Step_2_%EB%8D%B0%EC%9D%B4%ED%84%B0_%ED%94%84%EB%A0%88%EC%9E%84_%EA%B5%90%ED%99%98
웹 소켓 모듈이 인코딩된 메세지를 디코딩하고 on event에 걸린 콜백 함수를 실행하기까지의 시간이 오래 걸리는 것을 알 수 있었다.
그래서 웹 소켓 동작을 thread 를 나누어서 수행하고 싶은데 무슨 방법이 없을까 찾아 보던 와중
Web Worker 를 도입하게 되었다.
웹 워커란 ? 스크립트 thread로 만들어서 스크립트의 기능을 수행하게 한다.
출처 LINE Engineering
워커 와 스레드는 postMessage 로 message 로 줄 수 있으며 onmessage 메시지를 받아 이벤트 핸들러로 동작하게 된다.
socket io 가 스크립트로 동작을 할 수 있어서 다행히도 워커를 만들 수 있었다.
importScripts("https://cdnjs.cloudflare.com/ajax/libs/socket.io/3.0.1/socket.io.min.js");
const socketURI = "serverURI";
const socket = io.connect(socketURI, {
transports: ["websocket"],
upgrade: true,
});
self.onmessage = function (e) {
const data = e.data;
socket.emit("someEvent", data);
}
socket.on("anyEvent", (data) => {
self.postMessage(data)
})
이렇게 코드를 짜서 워커에서 웹소켓 동작을 구현할 수 있었다.
워커에서 웹소켓이 돌아갔을 때 시간이 많이 단축되었는데
10배가 감축될 수 가 있었다. (감축된 시간도 만족스럽지 못하다... context api 로 상태를 변화시키는데 시간이 걸린다)
이렇게 워커를 도입하면서 스레드로 돌려 시간을 감축하고,
생각외로 웹소켓이 시간이 걸리다는 것을 알 수 있었던 경험이였다!