쓰레드를 생성하는 자체에 오버헤드가 존재합니다.
따라서, 쓰레드가 생성되자 마자 어떤 태스크가 주어지면 견디기 힘들어지죠.
쓰레드는 쓰레드 답게 작고 빠르게 움직여야 좋죠.

흔히, 100 개 ~ 200개 정도씩 쓰레드 풀을 만들어
미리 생성시켜두고 쓰레드의 사용을 멈추어도 메모리에서 해제하지 않는 식의 처리가
성능에 유리합니다. 현재의 풀 사용율이 70%가 넘으면 여유시간에 다음 풀을 준비한다든지 하는 스캐쥴링이
사용되기도 하구요.

그런데 구현상 태스크가 쓰레드라는 물리적 기반으로 굳이 나뉠 필요가 없을땐...
그냥 프로세스 한 개(쓰레드 한 개 짜리)가 모든 접속을 처리하게 설계하는 경우도 많습니다.
즉시 응답이 가능한 테스크일 경우에 유효하겠지요. (DB 쿼리 같은게 필요 없는 단순 채팅이나...)

결국은 쓰레드란 것 도 단순한 매카니즘입니다.
CPU란 녀석은 쓰레드란 걸 알지 못합니다. OS가 제공해주냐 마냐의 문제니까요.
쓰레드가 낫냐 프로세스가 낫냐란 문제는 어느정도의 접속자가 어떤식의 태스크를 필요로 하는지에
의해 판단될 문제이지, 무조건 쓰레드를 쓴다고 가벼운것은 아니고,
멀티 프로세스 기반에 비해 멀티 쓰레딩 기반이 약간 가벼울 수 있다는 거죠.
프로세스 레벨의 컨텍스트 스위칭에 드는 비용 만큼요.
단일 프로세스/단일 쓰레드 기반이 위의 것들에 비해 훨씬 유용할 수도 있다는 걸 상기시켜 드리며...
조언 같지 않은 조언을 마무리해야겠네요.

관련 자료들을 찾아보시면 IOCP에 관한 내용도 보실수 있으실텐데... Win32 기반의 서버 솔루션이면
도입을 고려함직 합니다. (IOCP 기반에선 멀티 쓰레딩이 별 의미 없죠)