KLDP 사용 편의성 향상을 위한 작업 진행 현황

음 아직도 forum list 는 문제가 되는 듯 보입니다.

1. forum list 에서 아직 대략 4초 정도의 시간이 걸리는 것 같군요. 시간을 잡아 먹는 query 는 "마지막 포스트" 를 출력하기 위한 query 들입니다.

SELECT ncs.last_comment_timestamp, IF (ncs.last_comment_uid != 0, u2.name, ncs.last_comment_name) AS last_comment_name, ncs.last_comment_uid FROM node n INNER JOIN users u1 ON n.uid = u1.uid INNER JOIN term_node tn ON n.nid = tn.nid INNER JOIN node_comment_statistics ncs ON n.nid = ncs.nid INNER JOIN users u2 ON ncs.last_comment_uid=u2.uid WHERE n.status = 1 AND tn.tid = 6 ORDER BY ncs.last_comment_timestamp DESC LIMIT 0, 1

이 query 는 대략 1.4 초 정도를 잡아 먹는 군요. 거의 각각 1초 가까운 시간들을 이 "마지막 포스트" 를 출력하기 위해 잡아 먹고 있습니다. 이 기능을 빼면 0.x 초 내에 페이지를 띄울 수 있을 것 같습니다.

그리고, 각 forum list 에 들어갔을 때 listing 을 하기 위해 글 제목과 관련 정보들을 가져오는 query

SELECT n.nid, f.tid, n.title, n.sticky, u.name, u.uid, n.created AS timestamp, n.comment AS comment_mode, l.last_comment_timestamp, IF(l.last_comment_uid != 0, cu.name, l.last_comment_name) AS last_comment_name, l.last_comment_uid, l.comment_count AS num_comments FROM node_comment_statistics l, users cu, term_node r, users u, forum f, node n WHERE n.status = 1 AND l.last_comment_uid = cu.uid AND n.nid = l.nid AND n.nid = r.nid AND r.tid = 12 AND n.uid = u.uid AND n.vid = f.vid ORDER BY n.sticky DESC, l.last_comment_timestamp DESC, n.created DESC LIMIT 0, 25

도 대략 1초 정도 걸립니다. 이 부분은 개선할 방법이 없을까요? 마지막에 DESC 3번이.. temp table 을 생성하게 만들어서, article 이 별로 없어도 무조건 1 초 이상의 시간을 소요하는 군요. desc를 할 경우와 하지 않을 경우의 비교

mysql> explain SELECT n.nid, f.tid, n.title, n.sticky, u.name, u.uid, n.created AS timestamp, n.comment AS comment_mode, l.last_comment_timestamp, IF(l.last_comment_uid != 0, cu.name, l.last_comment_name) AS last_comment_name, l.last_comment_uid, l.comment_count AS num_comments FROM node_comment_statistics l, users cu, term_node r, users u, forum f, node n WHERE n.status = 1 AND l.last_comment_uid = cu.uid AND n.nid = l.nid AND n.nid = r.nid AND r.tid = 5 AND n.uid = u.uid AND n.vid = f.vid ORDER BY n.sticky DESC, l.last_comment_timestamp DESC, n.created DESC LIMIT 0, 25;

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | |

| 1 | SIMPLE | r | ref | PRIMARY,nid,tid | PRIMARY | 4 | const | 13987 | Using index; Using temporary; Using filesort |
| 1 | SIMPLE | n | eq_ref | PRIMARY,status,uid,node_status_type | PRIMARY | 4 | junseo.r.nid | 1 | Using where |
| 1 | SIMPLE | u | eq_ref | PRIMARY | PRIMARY | 4 | junseo.n.uid | 1 | Using where |
| 1 | SIMPLE | f | eq_ref | PRIMARY | PRIMARY | 4 | junseo.n.vid | 1 | |
| 1 | SIMPLE | l | eq_ref | PRIMARY | PRIMARY | 4 | junseo.n.nid | 1 | Using where |
| 1 | SIMPLE | cu | eq_ref | PRIMARY | PRIMARY | 4 | junseo.l.last_comment_uid | 1 | Using where |

mysql> explain SELECT n.nid, f.tid, n.title, n.sticky, u.name, u.uid, n.created AS timestamp, n.comment AS comment_mode, l.last_comment_timestamp, IF(l.last_comment_uid != 0, cu.name, l.last_comment_name) AS last_comment_name, l.last_comment_uid, l.comment_count AS num_comments FROM node_comment_statistics l, users cu, term_node r, users u, forum f, node n WHERE n.status = 1 AND l.last_comment_uid = cu.uid AND n.nid = l.nid AND n.nid = r.nid AND r.tid = 5 AND n.uid = u.uid AND n.vid = f.vid LIMIT 0, 25;

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

| 1 | SIMPLE | r | ref | PRIMARY,nid,tid | PRIMARY | 4 | const | 13987 | Using index |
| 1 | SIMPLE | n | eq_ref | PRIMARY,status,uid,node_status_type | PRIMARY | 4 | junseo.r.nid | 1 | Using where |
| 1 | SIMPLE | u | eq_ref | PRIMARY | PRIMARY | 4 | junseo.n.uid | 1 | Using where |
| 1 | SIMPLE | f | eq_ref | PRIMARY | PRIMARY | 4 | junseo.n.vid | 1 | |
| 1 | SIMPLE | l | eq_ref | PRIMARY | PRIMARY | 4 | junseo.n.nid | 1 | Using where |
| 1 | SIMPLE | cu | eq_ref | PRIMARY | PRIMARY | 4 | junseo.l.last_comment_uid | 1 | Using where |

이 부분이 없으면 글 리스팅이 되지 않으니.. 없앨수도 없는 부분이고.. 이 두 부분만 해결한다면 정말정말 쾌적해 질 듯 싶습니다만.. :-)

dormael 님의 건투를 ㅋㅋ

포럼 목록에서 난관에 부딪혔습니다. ㅡ,.ㅡ

기존 쿼리와 스키마를 들여다 본 결과 SELECT문의 변경이나 인덱스의 추가로는 큰 개선의 여지가 없을것 같습니다.
제가 아는 범위 안에서는요.

아무래도 drupal의 대부분 스키마를 보면 속도보다는 유연성이나 모듈 개발/사용의 용이성을 위해 설계된것 같습니다.

그나마 tracker모듈의 쿼리에서는 데이터 구성이 논리적으로 임시테이블을 피해갈 수 있는 꽁수가 있었어서 운이 좋게 개선을 시킬 수 있었지만 forum은 답이 안보이네요.

제 생각에는 현재 테이블들에 다른 테이블들의 field를 참조하는 foreign key 성격의 field들을 추가하지 않는 이상 어려울것 같습니다. 물론 그럼 insert, update, delete 쿼리도 다 변경되어야 하구요. 그럼 다른 문제가 발생할 가능성이 또 생겨서 별로 쓰고 싶은 방법은 아닙니다.

어찌해야 할까요?

http://drupal.org/node/51263

추가적으로 이 내용을 참고해서 최적화를 해야하지 않을까요?

순선님 말씀이 맞습니다...
그건 드루팔을 뜯어고쳐야 하는것이기때문에 그냥해본 소리였습니다 ㅜ.,ㅜ

내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.