엊그제 웹로직 엔지니어가 와서 몇십분 아규한 일이 있었다. 훗날 참고하기 위해 새로 알게된 내용을 정리해본다.
먼저 타 사이트로 부터 전달받은 내용이다. 전달받은 내용이니 다소 사실과 다를 수도 있다. 얼마전 모 고객사(L사)가 오픈을 했는데 파일 다운로드가 몰려서 극도로 느려지는 성능 이슈가 발생했다. 다운로드 테스트 페이지를 만들어 확인했더니 동시에 여러대 PC에서 다운로드 시도하면 웹로직에 행이 걸리는 현상(제니퍼 불기둥) 발견. 이를 먹서를 바꿔 해결했다고 한다. 웹로직 12c의 기본 먹서는 multi io [멀티 아이오] 먹서인데, 이를 native 먹서인 DevPollSocket [디이브이 폴 소켓] 으로 바꿨다고 한다. (이때 오류가 발생하였는데 웹로직 쪽 버그였고 so파일을 패치해서 먹서가 적용되도록 조치했다고 한다)
타 고객사에서 문제가 발생했으니 우리쪽도 동일한 제품의 오픈을 앞둔 입장이라 확인이 필요했다. 다운로드 테스트 페이지를 전달받아 돌려보니 똑같은 현상이 발생, 웹로직 엔지니어를 불렀다. 아규해보니 테스트 과정 자체의 문제도 있었고, 발생하는 현상도 달랐다.
1. 익스플로러의 최대 다운로드 개수는 5개
이번에 작성한 다운로드 테스트 페이지의 내용은 파일 2000개를 0.5초 간격으로 다운받는 것이다. 간단히 설명하면 윈도우 onload시 iframe을 2000개 만들고, 셋타임아웃 500 간격으로 1메가~4메가 크기의 파일을 2000개 다운로드 받는다.
그런데 ie11의 경우 최대 다운로드 개수가 5개라고 한다. 새 창으로 브라우저를 여러 개 띄워도 똑같다. 이를 변경하기 위해서는 레지스트리를 수정하면 되는데, 구글에 “ie 창 개수 변경” 등으로 검색하면 바로 나온다고 한다.
특별한 조치없이 한 PC에서 파일 다운로드를 여러개 걸면, 5개까지는 진행이 되지만 6개부터는 소켓만 잡아놓고 연결은 하지 않는다고 한다. 이렇게 되면 웹로직에 행이 걸리며, 이때 행이 걸리는 현상은 정상적이고, 웹로직 측에서도 별달리 할 수 있는 조치가 없다고 했다.
다시 말해 PC 1대에서 2000개를 다운로드 받는 테스트 페이지로는, PC 2000대에서 각각 파일 1개씩 다운로드 받았을 때의 현상을 재현할 수 없다. 전자는 당연히 행이 걸리게 된다.
2. 클라이언트 대역폭을 알고 테스트 해야함
레지스트리를 변경해서 익스플로러가 파일 2000개를 동시에 다운로드 받을 수 있다고 쳐도 테스트에는 한계가 있다. 클라이언트 대역폭의 한계 때문이다.
클라이언트 대역폭이 1메가라고 하면, 파일 다운로드 속도는 1메가가 나올 것이다. 그런데 2000개 파일을 동시에 다운받는다면 각각의 속도는 1메가 나누기 2000 의 속도가 된다.
확인결과 테스트 페이지를 돌린 PC의 대역폭은 2메가 정도였다고 한다. 대역폭은 어떻게 알아내는거냐고, ipconfig를 보면 되는거냐고 물어보니, 웹로직 엔지니어 왈, 그냥 용량 큰 파일 1개를 다운로드 받을 때 브라우저에서 표시해주는 다운로드 속도를 보면 된다고 했다.
기존에 우리는 고객사 본사가 아닌 그 옆의 사무실에서 테스트를 진행하고 있었는데, 이후 본사 사무실에서 직접 테스트를 돌려보니 확실히 개선된 현상을 확인했다. 실제 고객 PC에서는 클라이언트 대역폭이 커서 다운로드가 빨랐던 것.
3. 먹서와 파일 다운로드에 따른 행과는 관련이 없음
이건 웹로직 엔지니어의 주장인데, 먹서와 파일 다운로드, 나아가 행 걸리는 현상은 전혀 연관이 없다고 했다. 하지만 바로 얼마전 타 고객사에서 먹서를 바꿔서 현상을 해결다고 전달받은 입장이 있었기 때문에, 이론적인 배경을 떠나 주장에 동의하기 힘들었다.
그래도 웹로직 엔지니어의 말이 옳다고 가정하고 정리해보면, 먹서라는 것은 출입구다. 사용자가 접속했을 때 먹서라는 놈을 거치게 되는데, 먹서는 그냥 사용자를 바이패스 해주는 입구 역할이고 다운로드와는 상관이 없다고 했다.
그럼 질문을 바꿔서, 어떤 문제가 있어서 먹서를 교체해야 한다고 가정하면, 그 어떤 문제는 무슨 문제일까요 하고 뒤집어 물어보았다. 그에 따르면 먹서는 크게 2 종류가 있는데, 자바 먹서와 네이티브 먹서가 있다고 했다. 네이티브 먹서는 OS 자체에 있는 먹서를 활용하는 것인데, 이게 잘 동작하지 않을 경우 자바 먹서를 사용한다고 했다. 자바 먹서는 먹서를 자바로 구현한 것이니 OS 단에서 지원하는 네이티브 먹서보다 당연히 느리다고 했다. 다시 말해 먹서는 디폴트 값이 잘 동작할 경우 변경하는 경우가 없으며, 디폴트 먹서가 잘 동작하지 않을 때에만 변경한다는 이야기였다.
우리는 타 고객사의 문제를 전달받았는지라 현재 먹서를 그곳과 같이 네이티브 먹서인 DevPollSocket 먹서로 변경해달라고 했는데, 현재 이 사이트는 네이티브 먹서의 일종인 nio [엔아이오] 먹서가 적용된 상태이고, 네이티브 먹서가 잘 적용되어 있는한 변경할 필요가 없다고 주장했다. 네이티브 먹서가 잘 안돌아서 자바 먹서로 바꾸는 경우는 있어도, 네이티브 먹서에서 네이티브 먹서로 바꾸는 경우는 없다고 했다.
그래서 네이티브 먹서에서 다른 네이티브 먹서로 바꾸면 어떤 문제가 있냐고 물어보았더니, 아무 문제가 없지만 아무런 효과도 없을 것이라 답하였다. 바꿀 이유가 없는 것이지 바꿔도 무방하다는 대답을 들었다. 우리는 일단 타 사이트에서 DevPollSocket 먹서로 잘 돌았으니, 리스크를 낮추기 위해 DevPollSocket 먹서로 적용해두는 것으로 결론지었다.