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

권순선의 이미지

5월 20일~21일 사이에 KLDP의 사용 편의성 향상을 위한 몇 가지 변동사항들이 있어 공지 드립니다.

- 속도 향상: http://kldp.org/node/70379
dormael님, 김정균님 등의 노력으로 db 서버를 튜닝하여 상당한 속도 향상이 이루어졌습니다. 주말 동안 좋은 결과를 만들어 주신 두분께 진심으로 감사의 말씀을 드립니다.

- 익명 사용자 답글 제한: http://kldp.org/node/70432
익명 사용자의 답글이 대부분 스팸이라 답글은 올릴 수 있되 실제 사이트 게재는 관리자의 승인을 받은 이후에만 가능하도록 설정을 바꾸었습니다.

- Free Tagging 기능
별도로 공지하지는 않았지만 며칠 전부터 글 작성시 태그(키워드)를 기록할 수 있도록 하였습니다. 포럼 글이나 블로그 글을 작성하실 때 꼭 본문의 내용과 관련된 키워드를 콤마(,)로 구분해서 추가하여 주시면 감사드리겠습니다. 현재까지 추가된 태그는 http://kldp.org/tags 에서 보실 수 있습니다. 태그 페이지는 오른쪽 최상단 메뉴에도 추가되어 있습니다.

- 글 올릴 때 <embed> 태그 사용 가능
<embed> 태그를 사용할 수 있게 설정을 바꾸었습니다. 이제 플래쉬 등을 자유롭게 링크하실 수 있습니다. 혹 추가하였으면 하는 html 태그가 있으면 알려 주십시오.

감사합니다....

관리자 주제: 

댓글

1day1의 이미지

정말 많이 빨라졌네요. 이제 KLDP 사용이 쾌적해지겠습니다.(평일 사용자가 많은때도 테스트를 해봐야 겠죠)
검색부분도 결과가 어느정도 만족스러운 것 같습니다.

http://kldp.org/tags 는 각 tag 가 구분이 쉽지 않네요.
왼쪽하단의 "tags in 카테고리" 처럼 tag cloud 형식으로 보이면 그나마 나을 듯 합니다.
아직 tag 를 입력한 글이 적어서 인가요? => 수정( 테스트 해보니, tag 설정한 글이 적어서 이군요. tag cloud 형식으로 나옵니다)

그리고 하나 궁금한 것이 있습니다.
왼쪽 메뉴의 RSS생중계 가 rss feed 를 읽어오는 것 같은데, 이것을 각 사용자가 자신이 원하는 rss feed 를 등록하여 사용할 수는 없나요?
현재의 RSS생중계는 별로 효용성이 없어보여서요.(저만 그런가?)

F/OSS 가 함께하길.. (F/OSS서포터즈,F/OSS서포터즈그룹)

F/OSS 가 함께하길..

wariua의 이미지

익명 사용자 댓글 제한은 다소 아쉽긴 하지만 당장 captcha가 제대로 안 된다고 하니 별 수가 없네요. 제 경우는 5월 19일 버전 받아서 해보니까 별 무리 없이 동작하던데 이상하네요. 하긴, 동시 사용자가 평균 1명이 안 되는 개인용 사이트이니 부작용 내지는 오작동의 여지가 훨씬 적기는 합니다만...

검색을 하다 보니 공백이나 구두 문자로 구별되는 단어만 검색이 가능하다는 (즉 "호랑이"로 검색하면 "호랑이가" 어절은 검색이 되지 않는다는) 점이 눈에 뜨이더군요. 이전에 한동안 상당한 트래픽을 유발했던 여배우 사진 모음 글타래를 찾으려고 "여배우", "여배우는" 등으로 시도해 보다가, 결국 자게 글목록을 한 페이지씩 거슬러 올라가 찾았다는... '어느 아는 사용자'도 있더군요... 쿨룩;;
----
$PWD `date`

$PWD `date`

권순선의 이미지

검색 부분이 말씀하신 대로 동작한다면 큰 문제로군요. CJK를 위한 검색 모듈 수정/재개발이 불가피하겠네요. 큰일입니다...

김정균의 이미지

조사를 인식을 한다면, 아마도 drupal 의 검색이 full text search 를 이용하는 듯 싶습니다. 요즘 mysql full text search 의 indexing 이 user define 이 가능한지 모르겠는데, 불가능 하다면, 검색은 다른 방도를 찾아야 할 겁니다. 조사를 띄어낸 색인을 만들어야 하는데..

김정균의 이미지

음 아직도 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 님의 건투를 ㅋㅋ

dormael의 이미지

ㅡ,,ㅡ

김정균님 우선 지금 방식으로는 작업하기에 무리가 좀 있을것 같습니다.
테스트 환경이 따로 없어서요. 제가 drupal의 구조나 module의 api를 정확히 이해하고 있지 않아서 좀 위태롭게 수정하고 있습니다.

가능하면 현재 시스템과 완전 떨어진 (같은 기계에 있는것 까지는 문제 없지만, database도 따로, url도 따로 접근할 수 있어야 할것 같습니다.) 환경에서 작업을 해야할 것 같습니다.

drupal도 복사해서 다른 계정으로 접근해서 수정할수 있게 해주시고, database도 새로 만들어 주세요.
계정도 kldp_test, database도 kldp_test로 하면 되겠네요.

월욜부터는 퇴근시간 이후에나 가능할것 같네요.. 아님 회사에서 몰래.. ㅋㅋ

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

권순선의 이미지

삼정데이터시스템에서 제공해 주신 마루타 용도의 기계가 한 대 있습니다. 그곳에 계정을 만들어 드렸고, 상세 내용은 메일로 보냈습니다. :-)

IsExist의 이미지

많이 빨라 졌습니다.

---------
간디가 말한 우리를 파괴시키는 7가지 요소

첫째, 노동 없는 부(富)/둘째, 양심 없는 쾌락
셋째, 인격 없는 지! 식/넷째, 윤리 없는 비지니스

이익추구를 위해서라면..

다섯째, 인성(人性)없는 과학
여섯째, 희생 없는 종교/일곱째, 신념 없는 정치

---------
간디가 말한 우리를 파괴시키는 7가지 요소

첫째, 노동 없는 부(富)/둘째, 양심 없는 쾌락
셋째, 인격 없는 지! 식/넷째, 윤리 없는 비지니스

이익추구를 위해서라면..

다섯째, 인성(人性)없는 과학
여섯째, 희생 없는 종교/일곱째, 신념 없는 정치

dormael의 이미지

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

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

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

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

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

어찌해야 할까요?

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

권순선의 이미지

그렇군요... 그럼 뭐 할 수 없죠. drupal.org 에 어떻게 이슈를 제기하는 것이 좋을지에 대해서 논의해 보았으면 합니다. 현재 drupal이 대용량 사이트를 지원하기 위해 해결하여야 할 문제가 무엇인지, 그리고 개발자들에게 바라는 바는 무엇인지 등...

감사합니다...

권순선의 이미지

참고로 현재 KLDP의 전체 글타래 수는 총 70208개, 글타래에 달린 답글 수는 총 332299개입니다. 이 정도면 전세계의 다른 drupal 레퍼런스 사이트들 중에서 얼마나 큰 축에 속하는지 궁금하네요.

7339989b62a014c4ce6e31b3540bc7b5f06455024f22753f6235c935e8e5의 이미지

쿼리를 잘라서 여러번 날리면 안될까요?
1차로 포럼 목록을 가져온 후 각 포럼 별로 마지막 글을 알아내는 쿼리를 따로 날리는 겁니다.
수정: 죄송합니다. 잘못 봤군요. ;; 그런데 삭제 링크는 어디갔나요?

dormael의 이미지

http://drupal.org/node/51263

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

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

mirr의 이미지

요즘 UDF에 대한 관심이 꽤나 늘고있는데 이건 배보다 배꼽이 더 커지는 행동이겠죠? ㅡ.,ㅡ::::
저는 제 회사의 디비개선문제를 위해 이 UDF로의 변경을 꽤나 유심히 살펴보고 있거든요.....

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

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

dormael의 이미지

미르님 udf가 뭔가요?
구글에게 물어보니 universal disk format이라고 나오고
mysql의 user defined function도 나오는데..
뭔가 다른건가요?

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

권순선의 이미지

user defined function일 것 같습니다. :-)

mirr의 이미지

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

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

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

wariua의 이미지

제안입니다.

interwiki 모듈 어떨까요?

위키에서 "WikiPedia:Some_word" 식으로 링크를 만드는 기능을 구현한 모듈입니다. KLDP wiki 페이지나 google 검색 결과, kldp.org 내의 다른 글에 대한 링크를 "[wiki:GentooDevelopmentGuide]", "[google:붕가붕가]", "[node:70438|KLDP 사용 편의성 향상을 위한 작업 진행 현황]" 식으로 만들어 줄 수 있습니다. google이나 wikipedia 같은 세계 공용 사이트의 경우 bbcode 모듈에 구현되어 있습니다만 당연히 하드코딩입니다. interwiki 모듈은 관리자가 인터위키 키워드를 유연하게 관리할 수 있습니다. 사용 형식을 다소 조정할 수 있으며 ("[wiki:...]" vs "[[wiki:...]]", "[wiki:link|설명]" vs "[wiki:link 설명]") URL의 공백 처리와 관련해서도 신경을 써서 작성되었습니다.

솔직히 굉장히 유용하거나 많은 사람들이 사용할 거라는 생각은 들지 않습니다만, KLDP wiki 및 KLDP.net과의 연계 강화에 아주 약간이나마 도움이 되지 않을까 하여 제안해 봅니다.

& http://kldp.org/node/69197#comment-334595 댓글의 내용도 한번 확인을 부탁드립니다. 메뉴 항목에 "검색"을 추가하는 것에 대한 것인데, 자리한 글타래가 워낙 시끌벅적해서 그냥 묻혀버릴까봐 굳이 다시 적어봅니다.
----
$PWD `date`

$PWD `date`

댓글 달기