이영규 님이 쓰신 글 :

: 임프님 말씀에 공감합니다.
: 전 여기보다 빠른 게시판을 본적없습니다, 윈도우즈기반에서는.
: 유닉스기반인 크레이지게시판은 자료수 5000넘으면 느려지고..
: 어떻게 여기는 윈도우즈기반인데 유닉스기반보다 더빠른것 같군요.
: 뭐 윈도우즈니 유닉스니 하는 것보다, 사실상 CPU성능이 DB속도를 좌우합니다만.
: 프로그래밍적인 측면에서는 '이보다 더빠를순 없다' 입니다.
: (*참고로 윈도우즈기반은 두루넷(www.thrunet.com)이나 클럽포유(www.clubforyou.net)가
: 있습니다만, 이곳과 속도차이를 한번 비교해보시기 바랍니다. 그것도 억세수 수에 따라 다르긴 합니다만.)
:
:


다시 임프랍니다.

음.. 칭찬 감사하구요. ^^
여기 게시판의 구현방법에 대해 몇가지만 말씀드립니다.

유닉스/리눅스 베이스의 크레이지웹보드의 소스를 분석할 기회가 없었습니다만, 적어도 크레이지
보다 빠를 수밖에 없는 이유는 있습니다. NT 베이스에서 ISAPI로 cgi를 구성하면 쓰레드가 캐시
되므로 리눅스보다 더 빠를 수밖에 없습니다.
일전에 어떤 분이, "델파이나 빌더로 cgi를 만들면 크기가 몇백k나 되는데 이걸 어떻게 cgi로
써먹나?"하는 푸념을 하신 글을 보았는데, 사실 그 말대로 cgi로 만들 경우 매번 메모리에
로드되는 시간이 엄청나게 느려지므로 당연히 반응속도가 느릴 수밖에 없습니다.

ISAPI는 그런 일반적인 cgi의 문제점을 충분히 보완해주죠. 더 큰 실행모듈 때문에 더 느릴 것
같지만, 한번 로딩되면 메모리에서 내려가지 않으므로 오히려 훨씬 빠릅니다.
물론 개발시엔 더 불편한 점도 있긴 합니다만.

두루넷이나 다른 NT 베이스의 게시판보다도 이 게시판이 빠른 것은 디비구조 때문입니다.
두루넷의 게시판 DB파일을 다운받아서 분석해보았었는데, 알고리즘 측면에서는 참 아름답게(?)
만들어놓았습니다만, 쿼리를 하는 시간이 몇배로 더 걸리게 되어있습니다. 이유는 Re 글을 검색
하는 부분의 알고리즘 때문입니다. Re 글의 레코드에서 Parent 필드로 다시 상위 글을 검색하므로
쿼리를 수차례 반복할 수밖에 없도록 되어있습니다.

저는 크레이지웹보드의 소스는 본적이 없습니다만, 그 동작방식에서 상당한 힌트를 얻었습니다.
프라이머리 인덱스외에 세컨더리 인덱스를 만들고, 화면에 보여질 순서대로 정렬하는 겁니다.
그래서 리스팅을 할 때 이 세컨더리 인덱스 필드 순서로 select 쿼리를 단 한번만 하면 되는거죠.
물론 이때는 하나의 필드가 더 필요하게 됩니다. Re 글은 화면상에서 얼마만큼 안쪽으로 밀려들어
가도록 (indenting)이 되어야 하므로 indent를 지정하는 필드가 더 필요하죠.
또한 상위 글이나 하위글을 직접 포인팅할 수 있기 위해서는 추가적인 필드가 필요합니다.
하지만 그 반면에 리스팅 속도는 눈부시게 빨라지죠. 간단히 말해서.. 쓸모없는(?) 필드를 몇개
더 추가함으로써 속도를 향상시켰다고 할 수 있습니다.

하지만.. 여러번 언급했듯이, 아직 버그가 꽤 많이 있습니다. 현재 아직까지도 글을 삭제하지
못하도록 막아놓았는데, 바로 세컨더리 인덱스를 바로 정정해주지 못하는 게시판의 버그 때문
입니다. 시간이 좀 나면... 빨랑빨랑 수정해서 멋지게 만들어보고 싶습니다만.. 밥먹고 살기가
꽤 힘들어서요. ^^;;

그럼 이만...