그누보드로 대용량시 서비스 문제점.

그누보드로 대용량시 서비스 문제점. 정보

개발자 그누보드로 대용량시 서비스 문제점.

본문

1. 모든 페이지에 db connection을 무조건 하게 된다.

_common,php, common.php 를 모든 페이지에 include 되게 되는데,

common.php 에서 무조건 db connection을 하게 된다.

2. 모든 페이지에 db 쿼리를 무조건 하게 된다.

- 예) select * from g4_config

그누보드에 대한 global config 를 db에 저장하게 됨으로써 무조건 쿼리하게 된다.

3. 불필요한 include를 많이 한다.

- 위의 common.php 의 경우 common.lib.php (덩치가 크다) 와

extends 디렉토리를 모두 페이지에 로딩시킨다.

불필요한 메모리 낭비와, 메모리 적재로 인한 시간이 엄청 소요됩니다.

그누보드에서 어떻게 대용량, 고가용성 서비스를 할수 있는지에 대해서 소스 레벨에서 체크하고 있습니다.

(고가용성 서비스는 초당 페이지 처리 회수가 c10k, 즉 1만을 처리할수 있는 서비스입니다.)

접속자 기준으로 하면 대략 2-3만명을 처리할수 있을것입니다.

하드웨어 레벨에서는 분산처리가 되어야 하고, 소스 레벨에서는 구조변경과, 소스 리팩토링, 캐싱 정책들이

들어가야 합니다. 기존의 그누보드 구조를 많이 벗어나게 되면 유지보수의 이슈가 생기니까,

최대한 현 그누보드 구조를 유지하는 상태에서 적용할 예정입니다.

이부분을 고민하면서, 처음으로 그누보드가 템플릿 엔진 기반이 아닌게 단점이라는 생각이 들었습니다.

같이 공유하면 좋은 부분들은 다시 올리도록 하겠습니다.

그럼.

댓글 4개

지운아빠 자기소개 아이디로 검색 회원게시물

자기소개 아이디로 검색 회원게시물

12.02.03 17:58:22

다 알아듣는 건 아닌데 구조적인 부분에 있어서 '제가 알아듣는 선에서' 동감이 가네요.

시시시 홈페이지 자기소개 아이디로 검색 회원게시물

홈페이지 자기소개 아이디로 검색 회원게시물

12.02.07 13:28:55

유지보수 부분을 해결하기위해서는
기본 환경설정 은 DB와 confg.cfg.php 파일 형식두가지로 구현하고
그 형식을 가지고 디비 접근이 필요없는 부분에 대해서만
심플한 common_s.php파일을 따로 구성해서 _common.php 또한 _common_s.php로 별도 파일로
구성해서 쓰면 되지 않을까 싶습니다.
원판 파일들을 건드려 버리면 아무래도 별도로 갈것 아니면 유지보수에서 너무 손이 많이 가버릴것 같고...
그리고 고용량, 고가용성으로 갈려면 커스트마이징을 다 뒤집듯이 하던지 아니면
로직을 완전 다시 짜야하지 싶네요..