테스트 사이트 - 개발 중인 베타 버전입니다

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

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개

다 알아듣는 건 아닌데 구조적인 부분에 있어서 '제가 알아듣는 선에서' 동감이 가네요.
유지보수 부분을 해결하기위해서는
기본 환경설정 은 DB와 confg.cfg.php 파일 형식두가지로 구현하고
그 형식을 가지고 디비 접근이 필요없는 부분에 대해서만
심플한 common_s.php파일을 따로 구성해서 _common.php 또한 _common_s.php로 별도 파일로
구성해서 쓰면 되지 않을까 싶습니다.
원판 파일들을 건드려 버리면 아무래도 별도로 갈것 아니면 유지보수에서 너무 손이 많이 가버릴것 같고...
그리고 고용량, 고가용성으로 갈려면 커스트마이징을 다 뒤집듯이 하던지 아니면
로직을 완전 다시 짜야하지 싶네요..
그누보드 엔진?이 바뀌지 않는 한 대용량은 어렵다고 봅니다.
DB 튜닝을 하긴해야 합니다.
전에 있던 모 회사에서
3만 명 정도에 한번 멈췄는데 튜닝후에 20만명정도 넘어도 아무문제 없었습니다.

게시글 목록

번호 제목
3790
15861
15855
15852
15849
15846
15844
15835
3788
15834
15833
15826
3787
15823
15821
3784
15820
3770
26217
26211
15816
15814
3762
3757
3748
15813
3746
3744
30006
15807
3742
15804
15801
15799
Flash AS3.0 1
15794
15791
15788
15787
3738
15784
15781
15777
15775
30001
15773
15772
3734
3731
26208
26205
3728
15770
29997
3720
15766
26197
15765
15763
3719
24341
15758
3717
15753
15745
15740
15729
15728
15727
26196
26195
15709
15706
3714
3713
15705
15702
3707
29986
29983
29980
29974
29968
15695
15692
15690
15688
3706
3703
15679
15678
3699
29961
29960
15676
15673
15672
3695
15666
15664
15662