같은 소켓 서버도,
언어마다 기다리는 법이 다릅니다.

01

순위가 아니라 실패 지점을 봅니다.

같은 조건에서 어느 쪽이 빠른지를 재려면 하드웨어와 구현과 설정을 통제한 측정이 필요하고, 그런 측정 없이 순위를 매기면 근거 없는 주장이 됩니다. 그래서 이 화면은 숫자 대신 어떤 작업에서 어떤 방식으로 무너지는지를 비교합니다. 실무에서 런타임을 고를 때도 최고 속도보다 이쪽이 판단에 더 쓸모 있는 경우가 많습니다.

02

기다리는 작업과 계산하는 작업은 다릅니다.

네트워크나 디스크를 기다리는 동안에는 다른 일을 할 수 있지만, 계산이 도는 동안에는 그 자리를 비워 줄 수 없습니다. 한 줄에서 순서대로 일을 처리하는 방식은 기다리는 작업에는 아주 잘 맞고 계산이 무거운 작업에는 취약한데, 그 대비가 이 화면에서 가장 뚜렷하게 갈리는 부분입니다.

03

한 요청이 전체를 막을 수 있습니다.

화면에 함께 멈춘 연결 수를 표시하는 이유는, 문제가 그 요청 하나에서 끝나지 않기 때문입니다. 한 줄로 처리하는 구조에서 누군가 자리를 오래 붙잡으면 뒤에 선 요청 전부가 함께 기다립니다. 평소에는 잘 돌다가 특정 요청 하나 때문에 서비스 전체가 느려지는 상황이 이렇게 생깁니다.

04

동시성의 단위가 각각 다릅니다.

어떤 환경은 가벼운 작업 단위를 아주 많이 만들 수 있고, 어떤 환경은 운영체제의 실행 단위를 그대로 쓰며, 어떤 환경은 그 중간입니다. 이 단위가 무엇이냐에 따라 연결 하나당 드는 메모리와 만들 수 있는 개수가 정해집니다. 화면이 런타임마다 이 항목을 따로 표시하는 것은 동시 접속 수를 가늠할 때 먼저 봐야 할 값이기 때문입니다.

05

막는 방법도 함께 제시합니다.

각 조합마다 진단만 하지 않고 무엇을 두면 막을 수 있는지를 함께 적었습니다. 무거운 계산을 다른 곳으로 넘기거나, 한 요청이 쓸 수 있는 시간을 제한하거나, 동시에 처리할 수 있는 수를 제한하는 식입니다. 런타임을 바꾸는 것만이 답이 아니라는 점이 이 항목을 넣은 이유입니다.

06

컴파일 단계에서 막히는 경우가 있습니다.

어떤 조합에서는 실행 중에 문제가 생기는 것이 아니라 아예 빌드가 되지 않습니다. 여러 곳에서 같은 값을 동시에 만지려 할 때 그것을 미리 잡아내는 환경이 있기 때문입니다. 문제를 늦게 발견하느냐 일찍 발견하느냐의 차이이고, 그 대가로 처음 작성할 때의 부담이 커집니다.

07

코드 예시는 형태만 보여줍니다.

각 런타임의 코드 조각은 실행해 검증한 프로그램이 아니라 같은 일을 어떤 모양으로 쓰는지 비교하기 위한 예시입니다. 실제로 옮겨 쓰려면 오류 처리와 자원 정리가 더 필요하며, 화면의 짧은 조각만으로는 그 부분이 보이지 않습니다.

08

같은 작업을 네 번 반복합니다.

비교가 성립하려면 조건이 하나만 달라야 하므로, 네 런타임에 거는 작업은 완전히 같은 것으로 맞췄습니다. 각 환경의 장점이 잘 드러나는 작업을 따로 골랐다면 어느 쪽이든 좋아 보이게 만들 수 있고, 그런 비교는 판단에 도움이 되지 않습니다. 특정 런타임에 불리한 조합이 화면에 그대로 남아 있는 것도 같은 이유입니다.

09

약점은 대부분 우회할 수 있습니다.

어떤 런타임이 특정 작업에 취약하다는 것이 그 작업을 할 수 없다는 뜻은 아닙니다. 무거운 계산을 별도 프로세스로 넘기거나 전용 작업 큐를 두면 대부분 해결되고, 실제로 많은 서비스가 그렇게 운영됩니다. 그래서 이 화면의 판정을 런타임 선택의 결론으로 읽기보다, 그 런타임을 쓸 때 무엇을 미리 준비해 두어야 하는지의 목록으로 읽는 편이 맞습니다.