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

더 빠른 게시판을 위하여

· 10년 전 · 686 · 5

이 글을 쓰는 이유는 나중에 어떤 생각으로 게시판을 개발하였는지 찾아보기 위한 것으로 같은 조건에서의 테스트를 미리 방지하고자 하는 이유도 있습니다.

 

각 테스트에 쓰인 레코드의 수는 100만건이며, 주키와 순서를 정하기 위한 인덱스 그리고 제목 필드만으로 간단하게 사용하였습니다.

쿼리문에는 SQL_NO_CACHE 를 사용하여 캐쉬가 되지 않도록 하였습니다.

그리고 1 페이지에 20 레코드씩 노출하여 총 50,000 페이지가 되도록 하였습니다.

 

pid (주키)

oid (인덱스, 게시물 순서)

title (제목)

 

처음으로 키의 속도를 체크해 보았습니다.

 

예1)

http://www.gnutest.com/simple/t_list.php?page=50000 

 

order by 에 주키 또는 인덱스를 지정하지 않았습니다.

select * from table limit 0, 25;

와 같은 방식으로 사용하였습니다.

속도가 굉장히 빠른게 느껴지시죠. 

그렇지만 order by 를 지정하지 않았으므로 가장 먼저 쓴글이 가장 먼저 노출되어 게시판의 용도에 맞지 않습니다.

 

예2)

http://www.gnutest.com/simple/t_list.php?order=desc&page=50000 

 

order by pid desc 를 주었습니다.

속도가 현저하게 떨어지는 것을 느낄수 있을겁니다.

아마도 order by 에 키가 사용되지 않았을수 있으니 인덱스를 강제로 사용해 봅니다.

 

예3)

http://www.gnutest.com/simple/t_list.php?order=desc&page=50000&force=true 

 

속도가 1/3 정도로 줄어드는 것을 확인할수 있습니다.

select * from table force key(primary) order by pid

아마도 예2) 에서는 인덱스가 사용되지 않은것 같습니다.

 

여기까지 인덱스를 사용하지 않는것과 사용하는 것 그리고 인덱스를 강제로 사용하는 것에 대해 살펴 보았습니다.

100만건에서 50,000페이지의 속도가 1초대 이내 이므로 캐시 파일을 사용하지 않은것 치고는 훌륭하다고 할수 있을것 같습니다.

 

오늘은 여기까지 하고 다음에 또 뵈요.

 

댓글 작성

댓글을 작성하시려면 로그인이 필요합니다.

로그인하기

댓글 5개

다음버전은 제로보드와 같은 구조인가요??
XE CMS 말씀이신가요?
아네.. 개인적으로 본문게시물 table 과 댓글 table 이 분리되면 좀더 많은 부가기능이 나오지 않을까 하는 생각을 많이 했거든요.
본문과 댓글은 분리하여 테스트 해보고 있습니다.
다만, 댓글과 통합된 검색은 포기하거나 느리거나를 감수 해야겠네요.
저같은 경우 FK키로 처리를 했었는데 FK키로 처리하게 되면 부모의 PK 또는 INDEX를 바로 찾아들어가서 인덱싱을 제대로 타긴 하더라구요.

게시글 목록

번호 제목
28080
7612
7598
7595
19842
28079
19840
7593
28076
7590
28072
28065
19836
7586
28058
7573
31754
7552
28057
30993
28052
7546
7544
7538
7519
30992
19834
7517
7512
7511
19832
19820
7509
24658
7508
7507
19818
30990
7506
7505
7498
7492
28051
7481
30988
19813
19812
7477
7476
7471
7467
19810
7464
19809
7463
7457
30980
7450
28043
7447
7440
28040
7438
7430
7427
7423
7414
7408
7405
7401
7400
19808
7398
7393
7389
19805
7382
7379
7378
7363
7361
7356
19804
7355
7352
19786
7342
7336
7332
19783
7328
7325
7324
28036
19782
7321
26574
7314
7312
19781