아..아래 덧글들 보고 추가합니다.

- asp vs .net 에서 .net을 쓴다고 해도 지금 학규님이 얘기하신 정도의 웹 솔루션에서는 그다지 큰 advantage를 보기가 힘들다는겁니다.
대규모로, 복잡하고 구현해야 할게 많은 사이트도 아닌걸요..

참고로 현재 라게는 게시물 200만건, 코멘트 800만건을 MySQL+PHP로 돌리고 있습니다.
OS는 Linux
장비는 P3 1G Dual & Mem 2G X 3ea (DB 1ea, Web 2ea, L4 Switching)

음.. 저는.. 잘은 모르지만.. 부엉님께서 좀 무책임하시다는 느낌이.. 듭니다..

...라게 또 바꿔요? ㅠㅠ

음...부엉님 저기 순수 1달이 개발만 기간 이겠죠?

[기획이랑 디자인 뭐시기 하면 더 걸리지 않을까 생각하는데-_-]

라게 같은 경우 회원수도 많고 게시판도 여러개 있는데, 많은 회원들이 게시판을 액세스 할때 하나의 디비로 모두 접근하게 되면 부하가 많지 않나요? 라게의 사양정도면 접속자를 어느정도가 한계인가요? (동시 접속수라던가.. )

아 그리고 php, jsp, asp, asp.net 등 플랫폼마다 그런 성능차가 어느정도 나는지도 궁금합니다.. 지금은 게임서버가 ms-sql 이기 때문에 웹 쪽 디비도 ms-sql 로 가야 한다고 생각하고 있는 중이죠.

음.. 제가 알기로 게시판 액세스시 DB 접근 자체는 큰 부하가 되지는 않을 껍니다. 물론 모든 게시판 사용자들이 검색을 동시에 한다면 웬간한 서버로는 견딜 수 없을 테지만, 웹의 특성상 그런일이 잘 발생하지 않습니다. 게임은 long-connection을 기본으로 하고 있지만 웹은 conneciton을 유지 하지 않는 방식이며, 동시에 많은 요청이 들어왔을때 그걸 한번에 DB에 밀어넣는 따위의 무식한 짓을 하지 않도록 설계를 하게되죠. (DB Conneciton Pooling 등으로..) 그리고 MySQL 자체가 단순 쿼리의 경우 워낙 빠른 퍼포먼스를 보여주기 때문에 큰 문제는 없으리라 보여지네요.
그리고 웹 어플리케이션은 일반적으로 '동시 접속수' 같은 단위로 성능을 측정하지 않습니다. 보통 TPM(Transaction Per Minute) 혹은 TPS(Transaction Per Second)로 측정을 하여 전체 처리가능한 볼륨을 정의 하게 되죠. 대규모 금융 사이트들도 TPS 자체는 생각하는것 만큼 높게 나오지 않는답니다. ^^;
개인적으로는 아무래도 JBoss 같은 공개 Web Application Server + JSP/Servlet 을 권장하는 바입니다. 처음엔 작게 시작하겠지만 차차 사이트를 키워나갈려면 처음부터 제대로 구조를 잡는 편이 여러모로 미래를 위해서 도움이 될꺼라 생각이 드네요.

bard님의 말이 전적으로 맞습니다.
다만 개인적인 지향점으로 minimalize를 잡고 있는터라.. (어셈과 C로 프로그램을 시작한 탓이겠지요..)
웹 어플같이 단순한 것은 초기 설계가 확장 용이하고 하부 어플리케이션의 변경이 용이하도록 하는것이 주요하겠죠.
그래서 전 언어가 어떤것이던 일정 규모 이상을 개발할때는 꼭 Framework + App 구조를 사용합니다.
DB나 CGI에 대한 Interface 를 미리 만들어놓고 화면처리등은 템플릿으로 하고..뭐 이런거죠..
아, 이얘기 하려던게 아닌데..

암턴, 학규님께 하고싶은말은..
게시판 access자체가 DB에 큰 부담이 되지는 않습니다.
다만, varchar, text, blob 등에서 like '%word%' 검색을 할때가 cost가 많이 들어가는 주 원인이죠.
물론, 게시판 따위-_- 에서 join을 쓸 이유는 없다고 가정합니다.
이러한 검색쪽의 부담 역시 꼭 검색이 필요한 곳에 검색 솔루션 등을 적용하면 큰 무리는 없을거라 봅니다.
지금 라게에 적용하려고 예정인 것을 보면, MySQL의 Fulltext Indexing 을 Application level에서 구현하는 것을 만드는 중입니다.
그리고 역시 bard님이 언급하셨지만, TPS가 가장 큰 척도입니다.
현재 라게는 일평균 400만 hit의 web access가 발생합니다.
하나의 hit을 하나의 transaction으로 볼때, 하루평균 46TPS정도가 됩니다. peak 때는 60TPS정도 되는군요.
DB 기준으로는 평균 180QPS(Query Per Second), Peak 300QPS정도 나옵니다.
제생각에는 웹쪽은 한계성능에 달했고 (CPU의 Peak Time이 하루의 1/3을 예전에 넘었습니다. -_-), DB는 약간의 여유가 있는 정도입니다.
DB쪽을 중심으로 몇가지 말씀드리자면, (라게가 현재 꽤 큰 규모로 자라있기때문에 자꾸 참고해서 말씀드리는군요;;)
우선, MySQL아니라 어떤 DB라도 Index만 잘 써도 배 이상의 성능을 끌어낼 수 있다. 라는점입니다.
단적으로 한동안 라게의 프로그램에 약간 변경을 하면서 게시판의 select query쪽이 약간 변경되었는데, 실수로 index를 변경하는것을 잊었습니다.
그후 한동안 라게는 엄청난 과부하에 시달렸죠.
또, DB의 select가 가장 빈번하게 발생하기는 하지만, 주요한 부하가 되는 원인은 update, delete등의 변경이라는 것입니다.
DB Pooling을 사용하는 것도 이러한 변경을 모아서 처리하기 위한 이유도 있습니다.

두번째로, 플랫폼을 결정하고 기획하시기보다는, 기획에 플랫폼을 맞추는 것을 권장합니다.
분명하게 각 플랫폼마다의 장단점, 최적용도는 다릅니다. 자세한 기획도 모르면서 어떠한 플랫폼을 추천하기는 무리겠군요.
그리고, 게임서버가 ms-sql이라고 해서 굳이 웹까지 ms-sql로 할 필요는 없습니다.
사용자의 로그인 정보만 동일하게 유지할 수 있다면, 좀 더 폭넓게 고려하시기 바랍니다.
게임과 웹은 동작 환경이 전혀 다른 완전히 다른 세계인거지요. :]

php나 asp같은 인터프리팅 방식의 최대의 문제점은 매회 억세스마다 컴파일과 실행을 반복한다는게 있죠. 물론 가변성을 생각한다면
당연하다면 당연할지 모르겠지만 많은사람들이 보되 변동이 적은편인 것들. 예를들면 faq나 공지사항 같은것이 있겠죠. 이를 대비해서
html로 만드는것도 좋은방법입니다만 관련된 솔루션을 쓰는것도 좋은 방법이라고 생각합니다. 제가 밑에 적어놓은 젠드 퍼포먼스 슈트
도 기본적인 엑셀레이션 기능과 더불어 각 상황과 변수에 따른 캐쉬를 파일별로 지정할수있도록 되어있습니다. -php의 코어엔진 자체가
zend사에서 만든것이기에.. 치사하기는 하지만 엑셀레이션 효과도 무시할수가 없더군요.- 또한 트래픽을 생각해서 html페이지를 압축
형태로 송신한다던가 하는 기능도 있더군요. 플랫폼의 문제는 부엉님 말씀대로 로그인 정보만 동일하게 유지할수있다면 어떤것을 쓰더라도
관계없겠죠. 개인적으로 라그나로크의 AID연동방식이 마음에 듭니다..

한국에서 주된 DB부하의 원인이라고 한다면 검색도 있지만.. 이는 많은 해결책들이 나와있는 상태고 제가 요 몇년간 웹서버 운영하면서
느낀 주된 원인은 바로 소위 리플이라고 말하는 간단답글이더군요. 이게 백단위로 달리기 시작하면 트래픽도 트래픽이지만 대부분의
게시판이 답글1개당 쿼리1번을 주는경우가 많은지라 골아파지더군요; 이것도 지금은 해결책이 나왔을지 모르겠습니디만..

hungry//
당연한 얘기인겁니다. 웹사이트는 필요한 부분에만 Dynamic Content를 사용해야죠.
일주일동안 아무런 변동도 없는데 쓰잘데기없이 DB 접근을 하게할 필요는 없습니다.
그리고 역으로, DB접근이 너무 많으나, 사용자별로 다르지 않고 공통적인 부분은 Static HTML로 Generate할 수도 있죠.
현재 라게에서 /channel/channel.php.. 로 들어가는 메뉴링크가 그렇습니다. 아, 메인페이지하고요.
이것들은 현재 Linux의 cron을 통해 1분텀으로 만들어주고 있습니다.

음. 공연한 딴죽이 될지도 모르겠습니다만..
ZPS는 cacheing & compress 솔루션에 불과합니다. 현재 학규님이 물어보신것은 개발환경-플랫폼 을 얘기하는것이겠죠.
경험으로 보아 하드웨어 자원이 무척 제한적이거나, 엄청난 access가 있는경우가 아닌 이상 ZPS에 들이는 비용대비 효과는 그렇게 크지는 않습니다.
ZPS에 관한 것은 운영해 나가시면서 비용평가를 해 보신 후 사용을 결정하시면 될듯 합니다.

그런데 대체 어느 게시판에서 comment를 가져올때 한개당 1회의 질의를 던지나요?
제가 잘못 이해하는것이겠죠?
comment가 200단위를 넘기면, comment에 page를 적용하면 됩니다. 간단하죠. 현재 라게의 설문과 같은 방법입니다.

음.. php 에 mySql 로 하되, 웹에서 회원 가입하거나 비밀번호 변경할때 트리거로 게임 db 에도 계정정보를 생성, 변경하게 한다면 어떨려나요...

물론 게임 db 는 ms-sql

말씀드렸다시피 세부 기획을 하면서 플랫폼을 결정하시는게 좋습니다... ^^
게시판+지식in 이 전부라면, php+mysql 도 나쁜 선택은 아닙니다.
야후에서도 지식검색, 블로그 등 모든 서비스에 php+mysql을 쓰는것으로 알고있습니다.
블로그는 제가 작업에 참여했던거라 확실하고..
단지 장비 등 서비스 규모가 무척 큽니다. -_-;;

php on linux에서도 ms-sql로 연결이 불가능한 것이 아니니까요..
로그인 처리나 개인정보 수정같은 부분까지 php로 처리해도 무방할겁니다.

아아...참고로 MySQl에 Replication이라는 기능이 있습니다.
update, delete만 한 서버에서 처리하고, select는 다중화시킬 수 있는 기능이죠.
oracle의 cluster랑은 현격하게 급수창이가 납니다만..
100% sync하지 않아도 되는 데이터에 한해서 사용할 수 있을겁니다.
아무래도 원본과 replication된 자료와는 시간차가 있기 마련이니까요..

ZPS는 솔루션의 예시일뿐이고요; 제가 봐온 많은 -쓸만한-솔루션들이 주로 PHP기반하에 있다는 내용이 요지였습니다..만 설명이 부족했던듯.
뭐 제가 ASP나 JSP에 큰 관심을 안둬서 그런지도 모르겠습니다만.. 하드웨어 자원대 솔루션 가격대비에 대해서는 밑부분어딘가에 적어둔듯
하지만.. 꼭 ZPS가 아니더라도 일단 장비를 추가하면 지속적으로 유지관리비용이 소모된다는점에서 생각해볼만하겠죠.

한개당 1회의 질의라기 보다는 출력시에 과도한 부하가 걸려버릴수밖에 없는 그런 원리라서.. Page적용법이 있었군요. 상상을 못한(;)
역시 창의력이 중요한거 같습니다.

게임서버DB에 직접적인 접근이 가능할수도 있다는건 그리 권해드리고 싶지가.. 뭐 방식이야 여러가지 있겠습니다만 MYSQL에도 그런기능이
있군요; 처음알았습니다. 그런데 다중화를 사용할만한 규모의 사이트에서 어지간히 돈이 없지 않는한 MYSQL을 쓰지는 않을듯해요;

흠
My sql과 Ms,sql ASP.Net과 asp

1)My sql &Ms sql 장점
My sql공짜다.또한 대부분 리눅스 모드 즉 텍스트 모드에서 하기 때문에 편리하다.
Ms sql 이것 같은 경우는 모든 sql쿼리를 지원하기 때문에 쿼리를 날리기가 쉽고 스토어드나 뷰기능이 있어서 그만큼 좋습니다.
사용하는 것 또한 편리합니다.
2)My sql & Ms sql단점:My sql같은 경우는 Personal이기때문에 아주 큰 기반의 시스템에서는 무리라고 생각합니다.
또한 개발자 입장에서 쿼리를 날릴 때 꽤 노가다를 많이 해야 하고 그렇게 되면 코딩수도 늘어납니다.(서브쿼리나 스토어드프로시저,뷰의 미구현)
Ms sql같은 경우는 Enterprise급은 아니라는 것이 문제일수 있져
3)Asp.Net &Asp
이것 같은 경우 위에서 말씀하신 것처럼 Asp.Net같은 경우 많은 사용자가 접속할 경우 속도면에서 불리합니다.
또한 초짜 개발자가 이것을 사용할 경우 깊은 의미의 깨달음을 얻기 힘듭니다.(거의 모든 걸 툴을 이용하는지라...)
이러면에서 보자면 Asp같은 경우 그 의미의 깨달음을 얻기가 쉽습니다.그러나 .Net에 비하자면 개발 속도면에서는
불리합니다.

여기서 오라클이나 PHP는 설명하지 않도록 하겠구여(오라클은 써본적이 ㅋㅋㅋ 글구 PHP는 ASP와 성격이 유사합니다.)
결론:개발자분들은 이러한 개발도구에 얽매일 필요는 없다고 생각합니다.
어디까지나 이러한 개발도구들은 하나의 Application의 구현을 하나의 도구하는 것 그것을 명심하세요

P.S 아마도 앞으로의 개발도구시장은 .Net Framework와 같이 쉽게 쉽게 할수 개발할수 있는 도구로 나갈 것 같네요
제 생각이지만...