대부분의 개발자는 네트워크 처리방식(epoll 또는 IOCP)이 얼마나 많은 접속을 처리할수 있느냐에만 관심을
갖는다. 그러나, 문제는 네트워크 처리방식이 얼마나 많은 처리를 하느냐 보다 프로그램에서 얼마나 빨리 처리를
할수 있느냐에 따라 동접자가 결정이 된다는 것이다.
실 예로, 개발자들은 스트레스 테스트를 통해 동접자(동시접속자)수가 5000개 이상 처리 가능한 구조라는
식의 테스트 결과를 말한다. 이 결과가 틀렸다는 것은 아니다. 그러나 여기에서 빠진 가장 중요한
값이 있다는 것이다. == "데이터를 처리하는데 소요된 시간"이 테스트에서는 빠져 있다.
나도 프로그램을 하면서 이런식의 오류를 많이 범했다.
예를 들어 계산을 해 보자,
하나의 클라이언트가 초당 1KB(1024B)의 데이터를 서버로 동시에 1000개의 클라이언트가 데이터를 전송하고,
이중에 보낸 클라이언트를 제외한 999개의 클라이언트가 데이터를 전송 받는다고 할때
서버의 입력 데이터는
(1,024 * 1000) = 1,024,000
이지만,
서버에서 처리(전송)해야 할 데이터는
(1,024 * 1000) * 999 = 1,022,976,000
의 데이터를 처리(전송)해야 한다는 결론이 나온다. 전송 데이터 량으로 본다면 1G의 데이터를 전송해야
하는 데이터 량이다. 그냥 단순 수치상의 결과이지만 상당한 수치임은 분명하다.
하나의 클라이언트가 초당 1KB(1024B)의 데이터를 서버로 동시에 1000개의 클라이언트가 데이터를 전송하고,
이중에 보낸 클라이언트를 제외한 999개의 클라이언트가 데이터를 전송 받는다고 할때
서버의 입력 데이터는
(1,024 * 1000) = 1,024,000
이지만,
서버에서 처리(전송)해야 할 데이터는
(1,024 * 1000) * 999 = 1,022,976,000
의 데이터를 처리(전송)해야 한다는 결론이 나온다. 전송 데이터 량으로 본다면 1G의 데이터를 전송해야
하는 데이터 량이다. 그냥 단순 수치상의 결과이지만 상당한 수치임은 분명하다.
여기에도 분명한 오차는 존재한다. (발생 데이터에 대한 가공 부분이 바로 그것이다.)
또한, 이런 대량의 데이터를 처리하기 위해 개발자 들은 "쓰레드"를 사용하면 된다는 식의 답을 말한다.
그러나, 분명 오답이다. 쓰레드는 내부 데이터 처리를 빨리 하고자 할때 사용되는 방식으로, 이러한 구조에서
쓰레드는 전송해야 하는 데이터를 점점 많이 만들어 내게 된다.
(NIC은 쓰레드 처럼 병렬 처리가 아닌 직렬 처리 방식임을 알자!)
오히려, 안정성 적인 측면에서는 쓰레드의 사용 보다는 동시 접속 클라이언트 수를 제한하고 여러 하드웨어로
분산 처리하는 방식이 더 효율적인 방식이 되는 것이다.
정리.
- 입력 < 출력
- 출력 데이터량의 증가 = 쓰레드 수
중요한 것은 시스템이 좋아지는 만큼 데이터 처리량도 늘어난다는 것이다!