오랜만에.. 볼랜드포럼 서버에 대해 몇자 써볼까 합니다.

볼랜드포럼 서버의 하드웨어 사양은 제온 X3440 2.53GHz, 두 세대 지나간 린필드입니다. 메모리는 겨우 2GB고요.
(쿼드코어인데도 코어가 8개로 나오는 건 물론 하이퍼쓰레딩 때문이죠)

2GB밖에 안되는 낮은 메모리 사양인데 한번도 512GB 근처까지도 가본 적이 없답니다. 지금도, 겨우 330MB 근처죠?
(일반적으로 같이 쓸 일이 흔치 않은 DNS 서버 프로세스가 64MB나 먹고 있는 걸 감안하면 실제로는 더 낮은 거죠)
CPU도 비지한 시간대에도 10% 이상 잘 안올라가고, 바쁠 때도 5~7% 사이입니다.
주말이라 좀 한적한 건 맞지만 평일에도 큰 차이가 없습니다.

물론 CPU가 X3440이면 상당히 좋은 사양은 맞습니다. 하지만 현 시점에서 고사양 서버라고 할 수는 없겠고요.
지금 나오는 아이비브리지 기준으로는 i5 급보다도 낮고, i3보다 조금 나은 정도지요.
요즘 i7 급에서 가장 잘나가는 CPU가 i7 3770 정도인데,  i7 3770에 비해 포럼의 X3440 CPU는 절반 정도 성능밖에 안나옵니다.

2000년대 중반에는, 아예 애슬론XP 2300+ CPU와 PC용 메인보드를 따로 구매한 서버 랙케이스 서버를 조립해서 썼었습니다.
그때도 CPU 점유율이 50% 이상 넘어가는 경우는 거의 없었습니다. 그때는 포럼의 사용자가 지금보다 두배도 넘게 많았죠.

CPU 부하야 잘 감이 안오시겠지만, 메모리 사용량이 겨우 330MB 정도라는 건 실감이 바로 오실텐데요.
상당규모의 커뮤니티가 하나의 서버에 웹서버와 DB서버가 다 돌아가고 있는 것 치고는 메모리 사용량이 엄청나게 낮죠.
뭐 이건 윈도우XP 설치 직후 수준의 메모리 부하인 거죠. ㅎㅎ

어쨌든... 볼랜드포럼 정도의 상당한 규모의 커뮤니티에서, 사양도 좋지 못한 서버가 이렇게 부하가 낮다는 건 재미있지요.
리부팅한 직후에 캡쳐하거나 한 것도 아니고요, System Uptime 조회해보니 이번 부팅한 후 24일째 운영중인 상태입니다.
그렇다고 포럼 서버는 전혀 버벅거리거나 하지 않지요. 제가 아는 한 국내 어느 게시판보다도 느리지는 않습니다.


볼랜드포럼 서버가 고사양도 아닌데 이런 정도의 낮은 리소스로 쌩쌩하게 돌아갈 수 있는 것은 두가지 이유가 있습니다.

첫번째 이유는, 포럼의 메인 DB가 Firebird인 덕분입니다. 파이어버드는 RDBMS라고 믿기가 힘들 정도로 가볍습니다.
두번째 스크린샷에서 fbserver.exe가 파이어버드 프로세스입니다. 현재 메모리 31MB 먹고 있네요.
가볍고 메모리도 적게 먹지만 성능은 대단히 높아서, 메모리 먹는 귀신인 MS SQL이나 MySQL에 비해 비슷하거나 더 높습니다.

특히, 파이어버드는 리소스를 적게 먹기 때문에 하나의 물리 서버에서 웹서버와 디비 서버를 같이 돌려도 전혀 부담이 없는데요.
MS SQL이나 MySQL처럼 리소스를 많이 먹는 DB를 이렇게 단일 서버에 웹서버까지 함께 운영하면 성능이 확 떨어지죠.

더욱 더 좋은 건, 오픈소스라는 거죠. MySQL처럼 신경쓰이는 어정쩡한 오픈소스가 아닌, MPL 기반의 완전한 무료입니다.
MySQL이 오라클로 넘어간 후 미래가 불투명하고 불안해진 것과 달리, 파이어버드는 지금도 안정적으로 업버전되고 있습니다.


두번째 이유는, 네이티브인 ISAPI 방식의 웹서버 개발입니다. 볼랜드포럼의 게시판은 델파이로 개발된 네이티브 방식입니다.
제가 직접 개발한 거죠. 초기 버전은 C++빌더로 개발했었는데, 2000년대 중반쯤에 델파이로 포팅했습니다.
C++빌더나 델파이나 개발 난이도 면에서나 성능 면에서나 차이는 없습니다만, 델파이만 가능한 분께 소스를 넘겨주기 위해서였습니다.

뭐 스크립트 방식들 사이에서 뭐가 더 빠르다고 말을 하지만, 스크립트 방식은 네이티브 앞에서는 그저 도토리 키재기일 뿐이죠.
게다가 볼랜드포럼 게시판은 네이티브 중에서도 가장 고성능을 내는 ISAPI로 개발되어 있습니다.
여기 포럼의 개발자분들은 써보셔서 잘 아시겠지만 국내의 모든 게시판들 중에서도 최고의 속도를 보여주죠.

다만 ISAPI 기반의 네이티브 웹 개발은 스크립트 개발에 비해 어렵고 복잡합니다. 그래서 개발자가 생산성을 내기가 어렵습니다.
그래서 ISAPI 방식은 단일 사이트 개발에는 대단히 불리하고, 패키지, 솔루션 개발에 더 적합한데요.
스크립트 방식 웹개발이 워낙에 대세가 되다보니 패키지나 솔루션 개발에서도 ISAPI는 잘 안쓰이고 있습니다.

게다가 웹개발에서 성능 이슈는 서버 증설이나 하드웨어 스펙을 올리는 걸로 해결하는 게 일반적인 인식이 되다보니 더 그렇네요.
대부분의 웹 개발자들은 서버 사양 대비 성능을 끌어올리는 문제에 대해선 별로 신경을 안쓰는 분위기더군요.
개인적으로 많이 안타깝게 여기는 부분입니다. 개발자가 자체적인 성능 향상보다 하드웨어 스펙에 끌려다니다니...


그냥 포럼 서버에 들어가서 작업 좀 하다가 생각나서 써봤습니다.
서버 사양 대비 최대한의 고성능을 안정적으로 낼 필요가 있다면, DB로는 Firebird, 웹 개발 방식으로는 ISAPI를 고려해보시길. ^^