동일한 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"로 가는게 맞는 겁니까?

제가 서버측의 어플을 개발해보지 않아서 여기에 적절하게 답을 할 수가 없습니다. 서버
어플은 개발이 너무 어려븐거 가터요... ㅠ.ㅠ

서버어플 개발경험이 많으시거나, 여기에 적절한 답을 아시는 분은 답좀 해주십시요. 읽어
주셔서 감사합니다.