제가 경험이 아주 많다고는 할 수 없습니다만.. 나름대로 답을 해보겠습니다.
(더 많은 경험과 지식을 가지신 분이 계시다면 다시 리플 달아주시길.)

업로드를 위한 150개의 연결과 다운로드를 위한 40개 정도의 연결을 동시에 가지고 있고 쉴새없이
데이터를 주고받는다면 상당히 큰 부하이지만, 띄엄띄엄 오는 것이라면 그리 큰 부하는 아닙니다.
물론 서버 시스템의 사양에 따라 다르긴 합니다.

그리고 서버 애플리케이션 프로세스가 하나이든 두개이든 별 차이가 안 날 겁니다.
네트웍 연결을 맺고 끊는 부하라든지 쓰레드간의 스위칭 부하 등에 비하면 프로세스가 하나 정도
더 있는 것은 별 표도 안납니다.

사실, 말씀하신 정도라면, 코딩하기 편하게 쓰레드 동기로 하더라도 큰 무리는 없을 겁니다.
우연히 평균보다 많은 네트웍 연결이 몰리는 시간대에는 CPU 점유율이 좀 심각하게 올라가겠습니다만.
CPU 점유율이 너무 올라가서는 안되는 경우.. 그러니까 다른 중요한 프로세스가 한 시스템에서 동작하고
있다든지, 혹은 최대한 빨리 응답해야 한다든지.. 아니면, 예상했던 것보다 훨씬 더 많은 연결이
필요한 경우(수천개 단위 이상), 그런 경우라면 비동기, 특히 IOCP를 쓰실 것을 권합니다.
코딩이 좀 까다롭기는 하지만, IOCP는 수천개 단위 이상의 연결을 쉴새없이 맺고 끊을 때, 특히
1회 접속마다 전송 바이트수가 비교적 적을 때 이상적인 성능을 냅니다.

그리고.. 서버에서 DB 연결을 맺고 끊고 할 필요는 없을 겁니다.
자체적으로 DB 연결을 풀링하는 것이 좋습니다. 한번 연결한 DB 연결을 다 썼다고 끊지 말고
가지고 있다가 다음번 연결에 또 써먹는 겁니다. 그런데 이것은 아마도.. DB 서버의 동시접속 한계
내에서 제한을 받겠죠.
저는 주로 공개 DB인 파이어버드(무제한 사용자!)를 쓰기 때문에, 아무 생각없이 수백개이든 수천개이든
연결을 만들어놓고 쓰레드를 파괴할 때까지 뱉지 않습니다.
하지만 보통은 DB 접속자수가 제한되니까, 그 제한된 접속수 안에서 효과적으로 DB 연결을 재사용할 수
있도록 로직을 만들어야겠지요.

그럼...


박정모 님이 쓰신 글 :
:
: 동일한 DB를 접근하는 몇개의 속성이 다른 Client요청이 있고, 그 Client의 요청을
: 처리 해줘야하는 서버 사이드의 데몬(?)을 만들어야 합니다.
:
: 1. Client 요청
:
:   - 데이타를 실시간으로 업로드하는 클라이언트가 100개 이상(최대 150개) 있습니다.
:     이 클라이언트를 편의상 "업로드요청" 이라고 합니다.
:
:   - 웹 브라우저에서 데이타를 요청하는 약 30-40개 정도의 OCX가 있습니다. 이
:     클라이언트를 편의상 "다운로드요청" 이라고 합니다.
:
:   - 업로드요청은 100개의 요청이 5-10분 마다 한 번씩 한번에 동작합니다. 하나의
:     업로드요청은 한 번의 요청에 약 10K 정도의 데이타를 전송합니다.
:
:   - 다운로드요청을 발생시키는 것은 자동화된 프로그램이 아니라 웹브라우져를
:     동작시키고 있는 사람입니다. 그래서, 정해진 인터발이 있지는 않지만 최악의
:     경우 1초에 100개의 요청이 반복해서 발생할 수 있습니다.
:
: 2. 서버측의 환경
:
:   - DB는 MS-SQL을 사용합니다.
:
:   - 모든 Client의 요청은 하나의 P/G에 전달됩니다. 이 부분을 서버의 "AppPart"라고
:     합니다.
:
:   - AppPart의 모든 DB 요청은 하나의 P/G에 전달됩니다. 이 부분을 서버의 "DbPart"라고
:     합니다.
:
:   - AppPart와 DbPart는 별도의 P/G가 아니고, 하나의 *.exe 또는 Windows system의 서비스
:     입니다. 이 부분을 "서버P/G" 라고 합니다.
:
:     결과적으로 Client의 모든 요청은 하나의 서버P/G가 처리하고 이 P/G안에 Tcp소켓 모듈
:     과 DB와 연동하는 모듈이 들어 있습니다.
:
: 3. 질문 입니다.
:
:   - 질문 : 이런구조를 가진 C/S 모델에서 실제로 하나의 "서버P/G" 만으로 모든 클라이언트
:            요청을 수용합니까 ?
:
:   - 설명 : 만일에 "업로드요청"을 위한 "서버P/G" 와 "다운로드요청"을 위한 "서버P/G"를
:            별도로 두고 서로다른 포트를 열어서 서비스 해주는 모델로 간다면 그 효율이
:            많이 떨어 질까요?
:
:            이 질문에 "효율은 그다지 많이 떨어지지 않는다"고 대답하더라도, 일반적인
:            기업의 서버개발 방향이 하나의 "서버P/G"로 다양한 종류의 Client 요청을 처리
:            하는 쪽이므로, 하나의 "서버P/G"가 더 알맞다 입니까?
:
:            어쩌면 하나의 DB에 접근하는 "서버P/G"이므로 DB connection을 맺고 해제하는
:            등의 많은 시간을 요하는 부분때문에 하나의 "서버P/G"로 가는게 맞는 겁니까?
:
:  제가 서버측의 어플을 개발해보지 않아서 여기에 적절하게 답을 할 수가 없습니다. 서버
: 어플은 개발이 너무 어려븐거 가터요... ㅠ.ㅠ
:
:  서버어플 개발경험이 많으시거나, 여기에 적절한 답을 아시는 분은 답좀 해주십시요. 읽어
: 주셔서 감사합니다.
:
:
: