KLDP 좀 달라졌나요?
글쓴이: 김정균 / 작성시간: 토, 2009/02/28 - 1:27오전
얼마전에 제 홈페이지 QnA 에 박권신님이 올려주신 mysql tuning script 를 이용해서 kldp db 의 tuning 을 해 보았는데, 제 느낌에는 속도가 꽤 개선된 것 같은데, 여러분들은 어떠신가요?
일단, 기본적으로 kldp db 의 mysql 설정은 default my.cnf 를 사용하지 않고 어느정도 tuning 을 해서 (MyISAM 이었을 때는 제가 했고, 후에 정구현님이 InnoDB 로 tuning 을 하셨었습니다.) 사용하고 있었습니다만, 페이지 로딩시에 오래 걸리고 해서, http://www.day32.com/MySQL/ 에 있는 tuning script 를 이용해서 어느정도 tuning 을 했고, 그리고 각 테이블을 optimize 를 했습니다.
좀 달라지셨나요? 아니면 별 체감이 안나시나요? 또는 더 이상해 지셨나요?
댓글
.
흠.. 이런글 을 보면 태클이 심해서 ..;
설정파일 공개를 하면 어떨까요?
------------------------------------------------------------------------------------------------
Life is in 다즐링
------------------------------------------------------------------------------------------------
Life is in 다즐링
오우 좀 달라진것
오우 좀 달라진것 같습니다. 답글이 바로바로 올라가네요? -_-;;;
저는 게시물이 바로
저는 게시물이 바로 안올라 갑니다. 입력 버튼을 누르면 페이지 없음으로 뜨지만, 글은 게시되어 있네요. (2/27 21:00 경)
WinXP SP3, IE7 에서
WinXP SP3, IE7 에서 문제가 있습니다
뒤로가기를 누르면
..
에러가 납니다. 어쩌다 한번이 아니고 항상요.
빠르네요
페이지 로딩시간이 2배는 빨라진것 같네요
제 이름이
제 이름이 언급(?)되어 있어서 화들짝(?) 놀랐습니다만.. kldp의 로딩속도가 많이 좋아졌네요.
Firefox 3.x 사용중이고 별다른 문제는 없어 보입니다..
음... 미국에서는
음... 미국에서는 별로 체감이 안나는데요. :)
--
익스펙토 페트로눔
--
익스펙토 페트로눔
저는 조금더 빨라진 것 같습니다.
kldp 의 홈페이지 데이터량이 적어서 큰 체감은 없지만 빨라진 느낌입니다.
음!!
링크 누르자 마자 확 뜨는거...
뭔가가 느껴집니다. 머신을 업그레이드 했다거나 그건 아니죠??
---------------------------------------------------------------
폐인이 되자 (/ㅂ/)
---------------------------------------------------------------
폐인이 되자 (/ㅂ/)
일순 다른 사이트에 온줄 알았습니다.
쾌적하네요.. .
고생하셨습니다.
There is no spoon. Neo from the Matrix 1999.
There is no spoon. Neo from the Matrix 1999.
몇가지 브라우저로 둘러봤습니다.
Windows xp sp3에서 IE7, Opera 9.6, Chromium(build 10433), Safari 3.2 으로 kldp를
둘러 봤는데 확실히 로딩속도는 좋아졌고 별다른 이상 증상(?)은 없었습니다. :)
비스타 sp1 + firefox3.0
비스타 sp1 + firefox3.0 에서 잘 동작합니다.
전에도 느리진 않았는데 확실히 글 등록이 빨라졌습니다.
----
섬기며 사랑하면 더 행복해집니다.
개인 홈페이지가 생겼습니다 http://caoskernel.org
어셈러브를 개편중입니다 http://www.asmlove.co.kr
Vista SP1, Chrome에서 잘
Vista SP1, Chrome에서 잘 작동합니다.
최근 포스트나 기타 다른 페이지로 이동시에도 로딩이 많이 빨라진거 같습니다.
빠릿빠릿 하네요. 수고하셨습니다~ ;)
#################
Enjoy Life~!
#################
Enjoy Life~!
게시물을 2개 올려야
게시물을 2개 올려야 1개를 올릴수 있었던 문제가 사라졌습니다.
감사합니다.
제 경우 올리는 속도는 전과 같군요(답글 말고..).
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
RME 9636/52, RomIO, ESP 1010, Triton pro, K2600x, JV-80, Yamaha O3D, Tascam DA-30MKII... etc
http://blog.obbli.net
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
RME 9636/52, JV-80, Yamaha O3D, DA-30MKII, US-122MKII, Roland SC-55
http://blog.obbli.net
빠릿빠릿하네요
클릭하자마자 팍팍 뜨네요.
과장 쪼금 보태서 거의 로컬호스트에서 띄우는 수준인 것 같습니다.
수고하셨고 감사드립니다. ^^;
좀 나아지긴 했습니다만
제 경우 반응 속도가 가장 극악하다고 느끼던 것이 바로 점수 링크 부분입니다. 클릭을 하고 '한참'을 있어야 반응이 와서 점수가 올라가곤 했거든요. 처음 한동안은 클릭하는 습관이 잘못된 건가도 싶었는데 그렇지 않습니다. 방금 다른 글에서 점수를 올려보니 예전에 비해 반 정도로 줄어든 것 같긴 합니다만 여전히 어느 정도는 기다려야 하네요.
이런 툴이 있네요
수고하셨습니다. ^_^
여러가지 정보를 모아서 설정값을 변경해 주는거 같은데 정말 도움이 되겠네요.
물론 테이블 최적화 한것도 영향을 주었을 거라고 생각합니다.
감사합니다.
^_^
직접 조사해 가면서 해야되서 게으름을 피우고 있던 차에 감사합니다.
시간이 되면 슬로우 쿼리상의 느린것들을 참조해서 어플리케이션 수준의 쿼리 최적화가 가능할지 확인해 보겠습니다.
3월중에는 할 수 있겠죠...
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
흠... 저도 왠지
흠... 저도 왠지 optimize 가 가장 큰 효과를 발휘한 것이 아닌가 했습니다. table 체적화 한지 한 3년 됬거든요. 갑자기 생각나서 했는데.. 실제로 parameter tuning 은 별 효과가 없는 듯.. (이미 할 만큼 한 것이 아닌가 싶더군요.)
그리고 일단, DB 서버 메모리를 증설해야 할 듯 싶기도 하고요. tuning script 에서 모자르다고 하더군요 :-)
일단은 언뜻 몇가지 체크를 한 부분에서, drupal query 가 index 를 타지 않는 query 가 꽤 많이 있었고, disk 에 tmp table 을 생성하는 비율이 높다는 문제가 있습니다. (문서를 찾아보니 text field - tinytext 등.. - 와 blob table 은 memory 에 tmp table 을 만들지 않는다고 되어 있네요.)
시간이 있으면 index 타는 문제를 좀 고쳐 보겠는데.. 일단 여기까지 ^^;
흠 좀전에 페이지
흠 좀전에 페이지 로딩이 느려서.. show processlist 를 해 보았는데.. 다음과 같은 결과가 잡히더군요.
+--------+--------+-------------------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +--------+--------+-------------------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+ | 405483 | junseo | 172.16.10.6:56144 | junseo | Query | 14 | Locked | LOCK TABLES variable WRITE | | 405484 | junseo | 172.16.10.6:56145 | junseo | Query | 14 | update | INSERT INTO copyright_node (nid, cpyid, children_show_notice, children_allow_set, original_author) V | | 405486 | junseo | 172.16.10.6:56147 | junseo | Query | 14 | Locked | LOCK TABLES variable WRITE | | 405487 | junseo | 172.16.10.6:56148 | junseo | Query | 14 | Locked | LOCK TABLES variable WRITE | | 405488 | junseo | 172.16.10.6:56149 | junseo | Query | 12 | Locked | LOCK TABLES variable WRITE | | 405489 | junseo | 172.16.10.6:56150 | junseo | Query | 14 | Locked | LOCK TABLES cache_filter WRITE | | 405495 | junseo | 172.16.10.6:56156 | junseo | Query | 14 | Locked | LOCK TABLES variable WRITE | | 405496 | junseo | 172.16.10.6:56157 | junseo | Query | 13 | Locked | LOCK TABLES variable WRITE | | 405497 | junseo | 172.16.10.6:56158 | junseo | Query | 12 | Locked | LOCK TABLES variable WRITE | | 405500 | junseo | 172.16.10.6:56161 | junseo | Query | 14 | update | INSERT INTO cache_filter (cid, data, created, expire, headers) VALUES ('1:8b376d2b16f82a1bc03d73c87a | | 405501 | junseo | 172.16.10.6:56162 | junseo | Query | 14 | Locked | LOCK TABLES variable WRITE | | 405502 | junseo | 172.16.10.6:56163 | junseo | Query | 12 | Locked | LOCK TABLES variable WRITE | | 405503 | junseo | 172.16.10.6:56164 | junseo | Query | 12 | Locked | LOCK TABLES variable WRITE | | 405505 | junseo | 172.16.10.6:56166 | junseo | Query | 14 | Locked | LOCK TABLES cache_filter WRITE | | 405506 | junseo | 172.16.10.6:56167 | junseo | Query | 12 | Locked | LOCK TABLES variable WRITE | | 405507 | junseo | 172.16.10.6:56168 | junseo | Query | 14 | Locked | LOCK TABLES variable WRITE | | 405508 | junseo | 172.16.10.6:56170 | junseo | Query | 14 | Locked | LOCK TABLES cache_filter WRITE | | 405511 | junseo | 172.16.10.6:56173 | junseo | Query | 14 | Locked | LOCK TABLES variable WRITE | | 405512 | junseo | 172.16.10.6:56174 | junseo | Query | 14 | Locked | LOCK TABLES variable WRITE | | 405513 | junseo | 172.16.10.6:56175 | junseo | Query | 14 | Locked | LOCK TABLES variable WRITE | | 405515 | junseo | 172.16.10.6:56177 | junseo | Query | 14 | Locked | LOCK TABLES variable WRITE | | 405516 | junseo | 172.16.10.6:56178 | junseo | Query | 14 | Locked | LOCK TABLES variable WRITE | | 405517 | junseo | 172.16.10.6:56179 | junseo | Query | 14 | update | INSERT INTO variable (name, value) VALUES ('cache_flush', 'i:0;') | | 405518 | junseo | 172.16.10.6:56180 | junseo | Query | 42 | Locked | LOCK TABLES variable WRITE | | 405519 | junseo | 172.16.10.6:56181 | junseo | Query | 41 | Locked | LOCK TABLES variable WRITE | | 405520 | junseo | 172.16.10.6:56182 | junseo | Query | 41 | Locked | LOCK TABLES variable WRITE | | 405521 | junseo | 172.16.10.6:56183 | junseo | Query | 40 | Locked | LOCK TABLES variable WRITE | | 405522 | junseo | 172.16.10.6:56184 | junseo | Query | 39 | Locked | LOCK TABLES variable WRITE | | 405523 | junseo | 172.16.10.6:56185 | junseo | Query | 39 | Locked | LOCK TABLES variable WRITE | | 405524 | junseo | 172.16.10.6:56186 | junseo | Query | 35 | Locked | LOCK TABLES variable WRITE | | 405525 | junseo | 172.16.10.6:56187 | junseo | Query | 34 | Locked | LOCK TABLES variable WRITE | | 405526 | junseo | 172.16.10.6:56188 | junseo | Query | 33 | Locked | LOCK TABLES variable WRITE | | 405527 | junseo | 172.16.10.6:56189 | junseo | Query | 32 | Locked | LOCK TABLES variable WRITE | | 405528 | junseo | 172.16.10.6:56190 | junseo | Query | 32 | Locked | LOCK TABLES variable WRITE | | 405529 | junseo | 172.16.10.6:56191 | junseo | Query | 32 | Locked | LOCK TABLES variable WRITE | | 405530 | junseo | 172.16.10.6:56192 | junseo | Query | 29 | Locked | LOCK TABLES variable WRITE | | 405531 | junseo | 172.16.10.6:56193 | junseo | Query | 28 | Locked | LOCK TABLES variable WRITE | | 405532 | junseo | 172.16.10.6:56194 | junseo | Query | 27 | Locked | LOCK TABLES variable WRITE | | 405533 | junseo | 172.16.10.6:56195 | junseo | Query | 25 | Locked | LOCK TABLES variable WRITE | | 405534 | junseo | 172.16.10.6:56196 | junseo | Query | 23 | Locked | LOCK TABLES variable WRITE | | 405535 | junseo | 172.16.10.6:56197 | junseo | Query | 23 | Locked | LOCK TABLES variable WRITE | | 405536 | junseo | 172.16.10.6:56198 | junseo | Query | 21 | Locked | LOCK TABLES variable WRITE | | 405537 | junseo | 172.16.10.6:56199 | junseo | Query | 18 | Locked | LOCK TABLES variable WRITE | | 405538 | junseo | 172.16.10.6:56200 | junseo | Query | 17 | Locked | LOCK TABLES variable WRITE | | 405540 | junseo | 172.16.10.6:56201 | junseo | Query | 15 | Locked | LOCK TABLES variable WRITE | | 405541 | junseo | 172.16.10.6:56202 | junseo | Query | 14 | Locked | LOCK TABLES variable WRITE | | 405542 | junseo | 172.16.10.6:56203 | junseo | Query | 14 | Locked | LOCK TABLES variable WRITE | | 405543 | junseo | 172.16.10.6:56204 | junseo | Query | 13 | Locked | LOCK TABLES variable WRITE | | 405545 | junseo | 172.16.10.6:56205 | junseo | Query | 12 | Locked | LOCK TABLES variable WRITE | | 405546 | junseo | 172.16.10.6:56206 | junseo | Query | 11 | Locked | LOCK TABLES variable WRITE | | 405547 | junseo | 172.16.10.6:56207 | junseo | Query | 10 | Locked | LOCK TABLES variable WRITE | | 405548 | junseo | 172.16.10.6:56208 | junseo | Query | 10 | Locked | LOCK TABLES variable WRITE | | 405549 | junseo | 172.16.10.6:56209 | junseo | Query | 10 | Locked | LOCK TABLES variable WRITE | | 405550 | junseo | 172.16.10.6:56210 | junseo | Query | 10 | Locked | LOCK TABLES variable WRITE | | 405551 | junseo | 172.16.10.6:56211 | junseo | Query | 9 | Locked | LOCK TABLES variable WRITE | | 405552 | junseo | 172.16.10.6:56212 | junseo | Query | 9 | Locked | LOCK TABLES variable WRITE | | 405553 | junseo | 172.16.10.6:56213 | junseo | Query | 8 | Locked | LOCK TABLES variable WRITE | | 405554 | junseo | 172.16.10.6:56214 | junseo | Query | 7 | Locked | LOCK TABLES variable WRITE | | 405555 | junseo | 172.16.10.6:56215 | junseo | Query | 7 | Locked | LOCK TABLES variable WRITE | | 405556 | junseo | 172.16.10.6:56216 | junseo | Query | 6 | Locked | LOCK TABLES variable WRITE | | 405557 | junseo | 172.16.10.6:56217 | junseo | Query | 5 | Locked | LOCK TABLES variable WRITE | | 405559 | junseo | 172.16.10.6:56218 | junseo | Query | 5 | Locked | LOCK TABLES variable WRITE | | 405560 | junseo | 172.16.10.6:56219 | junseo | Query | 5 | Locked | LOCK TABLES variable WRITE | | 405561 | junseo | 172.16.10.6:56220 | junseo | Query | 3 | Locked | LOCK TABLES variable WRITE | | 405562 | junseo | 172.16.10.6:56221 | junseo | Query | 3 | Locked | LOCK TABLES variable WRITE | | 405563 | junseo | 172.16.10.6:56222 | junseo | Query | 2 | Locked | LOCK TABLES variable WRITE | | 405564 | junseo | 172.16.10.6:56223 | junseo | Query | 2 | Locked | LOCK TABLES variable WRITE | | 405565 | junseo | 172.16.10.6:56224 | junseo | Query | 2 | Locked | LOCK TABLES variable WRITE | | 405566 | junseo | 172.16.10.6:56225 | junseo | Query | 0 | Locked | LOCK TABLES variable WRITE | | 405567 | root | localhost | NULL | Query | 0 | NULL | show processlist | +--------+--------+-------------------+--------+---------+------+--------+------------------------------------------------------------------------------------------------------+cache 와 variable table 에 lock 을 거는 API가 bootstrap.inc variable_set function 과 cache_set 인데, 이 함수 호출이 사용하는 모듈만큼 하는 듯 싶습니다. 위의 결과로 보아서는 bot 몇 개가 동시에 확 들어왔을 경우 이렇게 table lock 이 걸리는 것이 로딩 지연의 문제점이 아닌가 싶군요. 음..
drupal 이 너무 많은 일을 db 에 의존하는 것이 문제가 아닌가 싶네요.
.
흐흐 많은 시스템을 다루시니 당연히 디비에 집중하는게 못마땅하시겟지만;;
저도 그렇고 =3
php와 mysql 만으로 pure 하게 구성하는게 배포와 운영에 좋으니까.. ( 손쉽게 )
그부분 때문이겠지요
------------------------------------------------------------------------------------------------
Life is in 다즐링
------------------------------------------------------------------------------------------------
Life is in 다즐링
drupal 은 text file 로
drupal 은 text file 로 처리해도 되는 것 까지 DB에 의존하는 것이 문제라고 보여욤.. 의외로 많은 cms 들이 이런 추세로 개발을 한다는.. 더군다나 drupal 의 경우 (정확히는 kldp 에서 사용하는 drupal) 한 페이지를 뿌리기 위해서 query 당 대략 4.5Mbyte 의 database data 가 웹서버와 db 서버간에 전송이 발생한다는 것도 문제죠. db 부하 때문에 sqlrelay 를 붙이려고 했는데, 자꾸 어느정도 이상 되면 잘려 버리기에 테스트를 해 봤는데, 무지막한 data를 전송하고 있어, sqlrelay 가 다 받지 못해서 잘리는 문제였습니다.
요즘 CMS들의 db 구조를 보면, 내가 그보다 잘 만들 능력은 당근 없지만, 옆에서 바라보고 있자면, 현장을 모르는 책상맨들이 기획한 것 같다는 느낌일까?? (음 쓰고 보니 표현이 이상하네욥..)
.
살짝 과격하신건 =3=3
약간 파일 기반으로 내려도 될것을 굳이 디비로 하는 이유는 이동의 간편성? 이라던가 백업때문인거 같습니다.
아무래도 그렇겠지요 ^_^;
------------------------------------------------------------------------------------------------
Life is in 다즐링
------------------------------------------------------------------------------------------------
Life is in 다즐링
저는 제가 모니터를
저는 제가 모니터를 언제 닦았는지 기억나지 않아서 한참 고민했었습니다. :-)
--------------------------
snowall의 블로그입니다.
http://snowall.tistory.com
피할 수 있을때 즐겨라! http://melotopia.net/b
뜨는건 예전보다
뜨는건 예전보다 팍팍 잘 뜨는 것 같습니다.
그런데 댓글 올리는 것은 여전히 느린 듯.. (현재시간 오전 ~8시 댓글 하나에.. 약 5~8초 걸립니다.)
온갖 참된 삶은 만남이다 --Martin Buber
빠른데요 뭘...ㅎ
메인페이지 들어올때부터 페이지 넘어갈때마다 속도가 더 빨라졌어요 ^^
----------------------------------------------------------
내가 아이에게 말했던 것은 무엇인가..
그것은 성공이라는 결과가 아닌..
치열함이 묻어나는 과정이었지..
그리고 앞으로의 전진..
무엇을 배워나가며 앞으로 걸어갈 것인가..
일어서자..
일어나야돼.... [록키발보아 중에서]
----------------------------------------------------------
----------------------------------------------------------
내가 아이에게 말했던 것은 무엇인가..
그것은 성공이라는 결과가 아닌..
치열함이 묻어나는 과정이었지..
그리고 앞으로의 전진..
무엇을 배워나가며 앞으로 걸어갈 것인가..
일어서자..
일어나야돼.... [록키발보아 중에서]
----------------------------------------------------------
이것 때문인지는
이것 때문인지는 모르겠으나, 저번 주말쯤 부터 tracker 에서 로그인이 항상 안됩니다. 전 tracker를 북마크로 해뒀는데 거기서 항상 로그인이 안되는군요.
메인페이지로 와서는 로그인이 됩니다. 어딘가에 버그가 있는 듯.
혹시 IE8 쓰십니까?
윈도우7에서 IE8로 접근하면 로그인이 될 때도 있고 안 될 때도 있습니다. 이유는 저도 모르죠. -_-;
파폭씁니다. 윈도도
파폭씁니다. 윈도도 그렇고 눅스도 그렇고 모두 그런현상이 나타나네요.
DB tuning 문제는 아닐
DB tuning 문제는 아닐 것 같고, tracker 의 문제일 듯 싶군요. 이건 구현님께 물어봐야 하나.. 쩝
많이 좋아졌어요.
솔직히 타사이트에 비해서 느린감이있었는데
많이 해소되었네요. 감사합니다.
---------------------------------------------------------------------------------
C(++)과 php 펄등을 공부하고있습니다.
반갑습니다! 리눅스 :-)
---------------------------------------------------------------------------------
C(++)과 php 펄등을 공부하고있습니다.
반갑습니다! 리눅스 :-)
반응속도가 확실히 좋아졌네여...
예전에는 한번 메뉴에 클릭해서 들어가면 3초이상 걸린게... 바로 들어가지니... 느껴지네여
[위선,거짓, 인간의 모든 추악함에서 꿋꿋이 살아가는 굶주린 영혼이여 편안한 휴식이 찾아오길 기원하겠습니다.]
[위선,거짓, 인간의 모든 추악함에서 꿋꿋이 살아가는 굶주린 영혼이여 편안한 휴식이 찾아오길 기원하겠습니다.]
이것도 튜닝하는데
이것도 튜닝하는데 유용합니다.
http://star4u.org
http://mirror.star4u.org
아 글 올리는 시간이
아 글 올리는 시간이 다시 매우 오래 걸리더군요. http://kldp.org/node/103527 올리는데 한참 화면이 멈추어져 있다가 빈 화면만 나오는 현상을 방금 겪었습니다. 최근글을 봤더니 올라가 있긴 하더군요.
답글은 거의
답글은 거의 느리다는 생각 안들고 바로바로 올라가네요~
권한님이 올려주신
권한님이 올려주신 스크립트도 돌려보니, 왠만큼 DB차원의 튜닝을 된 것 같습니다. 다만, tuning script 들이 한결같이 내뱉는 건.. 메모리좀 늘려야 겠어... 군요. 대략 12G 정도가 필요하다고 말들 하고 있습니다. :-)
kldp 서비스 내용에 비해서 너무 많은 메모리를 요구하고 있는데, 이는 drupal 의 구조상의 특성이라 보입니다. 즉, drupal = 메모리 잡아먹는 귀신.. 의 등식이 성립할지도 모르겠군요.
대충 권고사항은..
1. index 를 타지 않는 query 를 해결해 봐라..
2. SELECT DISTINCT queries without LIMIT clauses 와 같은 구문들을 어떻게 좀 해 봐라..
3. query 1개당의 전송량이 너무 많다..
등등을 내뱉고 있네요 :-)
그리고, 위에 멈추는 듯한 현상은 제가 위에 올려 놓았듯이.. slow query 로 인한 table lock 이 적체되는 것이 문제 입니다. 아마 table lock 을 걸지 않도록 하면 상당히 나아질 것 같습니다. table lock 의 주범이 cache 인데, kldp 의 login 사용자가 여기에 영향을 줄 정도의 drupal 기능을 사용하는 것으로 보이는 군요. 어쩌면 서버 부하는 올라가겠지만, cache 를 사용하지 않는 것이 view point 에서는 더 좋을 수도 있을 것 같군요.
캐쉬를 disable 하여
캐쉬를 disable 하여 보았습니다~ 지금 kldp db 서버에 달 수 있는 최대한의 메모리 용량이 16G네요. 이만큼 증설하려면 얼마정도 비용이 드는지 혹시 아시나용? 간단히 메모리 더 달아서 뭔가 해결이 된다면 고려 안해볼 이유가 없겠죠~ ^^
12G 정도로 늘리려면
12G 정도로 늘리려면 아마 기존의 램을 빼고 용량 높은 것으로 다시 넣어야 할 겁니다. 비용이 만만하지는 않을 걸요. 알아는 보도록 하죠.
메모리 증설이 좋긴 하지만
결국 데이터가 늘어나면 또 한계에 쉽게 이를것 같습니다.
저는 그것보다는 drupal6으로의 이전이 더 괜찮지 않을까 생각합니다..
단, 전에 drupal6에서 tracker나 forum등의 모듈들이 인덱스를 이용 못하던 테이블 구조를 인덱스를 탈 수 있도록 개선한다고 한 약속이 지켜졌을 경우가 전제입니다.
물론 전에 순선님이 말씀하셨던 것처럼 kldp에서 쓰이는 모듈들이 drupal6에서도 쓸 수 있어야 하는 전제도 포함이 되어야 겠죠.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
tracker/forum의 인덱스
tracker/forum의 인덱스 관련 부분 혹시 확인이 가능하실까요?
현재 사용하는 모듈들은 drupal6에도 모두 포팅된 것을 얼마전에 확인 했었습니다. ^^
우선 코드상이 아닌 체감으로 drupal.org를
확인해 보았습니다.
코드는 조금 시간이 되면 자세히 보도록 하겠습니다.
느낌으로 tracker는 상당히 빠른것 같습니다.
페이지 갱신을 하면 분명히 새로 갱신된 글이 있는데도 응답이 빠르네요.
하지만 forum의 경우 상당히 느립니다.
더 자세한건 유선에서 접속해서 확인도 해보고 나중에 시간이 나면 소스도 확인해 보도록 하겠습니다.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
아 한가지 방법이 더
아 한가지 방법이 더 있을듯... 지금 drupal 모듈을 아주 많이 사용하고 있는데 모듈들을 확 줄여버리고 최소한의 기능으로만 사용하는 것도...
글 보기, 답글
글 보기, 답글 올리기는 아주 상황이 좋아진 것 같습니다. 그런데 http://kldp.org/node/103550 글을 올리면서 재차 확인하였는데 여전히 글 올릴때 많은 시간이 소요되네요. 거의 30초 정도 기다린 것 같습니다. 이 문제... 메모리를 증설하면 해결될까요?
글을 올릴 때 오리지널 drupal과 대비해서 추가로 수행되는 쿼리가 무엇이고, 그러한 쿼리를 발생시키는 모듈이 무엇인지 좀 확인해 보면 좋을텐데 말이죠.
흠.. 지금 올리신
흠.. 지금 올리신 글로 테스트 해 보니, 올리는데 2초, 삭제 하는데 2초 정도 걸리는 군요. 그 당시에 다른 effect 가 있었던 것으로 보입니다. 글 등록시에 좀 오래 걸린다 싶으면, db 서버에서
의 결과를 첨부하면 찾기가 좀 더 쉬워 집니다.
네 지금은 잘
네 지금은 잘 올라가더군요~ ^^
지금 기억이 났는데...
전에 이것저것 최적화 한다고 하면서 LOCK TABLE, UNLOCK TABLE 부분을 코멘트 처리했던것 같습니다.
그런데 중간에 코어부분의 업데이트가 있으면서 다시 원복된것 같습니다.
지금은 주범인 cache를 꺼 놓은 상태라 코멘트 처리는 안해도 될것 같네요.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
엄청나게
엄청나게 빨라졌습니다!
http://www.ikpil.com
빨라졌습니다..
오.. 좋습니다..
고생하셨네요..
아직은 갈 길이 멀다
저도 로긴 문제가
저도 로긴 문제가 있었는데 금요일 부터인가 해결 되었더군요...
빨라지긴 빨라진것 같습니다..
--------
From Buenos Aires, Argentina
No sere feliz pero tengo computadora.... jaja
닥치고 Ubuntu!!!!!
To Serve My Lord Jesus
blog: http://sehoonpark.com.ar
http://me2day.net/sheep
--------
From Buenos Aires, Argentina
No sere feliz pero tengo computadora.... jaja
닥치고 Ubuntu!!!!!
To Serve My Lord Jesus
blog: http://sehoonpark.com.ar
http://me2day.net/sheep
로그인 문제 다시 생기는지 확인해 주세요.
사실 저도 구글 크롬에서 최근 포스트 페이지에서 로그인 안되는 문제가 있었는데 지금은 잘 되고 있습니다.
설정이 바뀐 부분이 페이지 캐시 기능을 끈것과 최근 포스트 페이지 모듈은 제가 만들었던 것에서 원래 drupal 기본 모듈로 바꾼 부분인것 같아서
최근 포스트 페이지 모듈은 다시 원복시켜 봤습니다.
저는 최근 포스트 페이지에서도 로그인이 잘 되는데 다른 분들은 어떠신가요?
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
다른건 모르겠고
다른건 모르겠고 훨~씬 빨라졌네요. 최근글 보기도 그렇고 개별 글이 뜨는 속도도...
참고로 제가 최근글 보기를 ktracker에서 그냥 tracker로 바꿨던 것은 일부 글의 경우 올라가긴 했는데 ktracker에서는 안 보이는 현상이 있었기 때문입니다. 그 문제의 원인이 무엇인지.. 그리고 혹 그 문제가 다시 발생하지는 않을까요?
근본적인 해결은 어렵겟지만
현재 구조상 근본적인 해결은 어렵습니다.
중간에 다른 모듈에서 에러가 나면 빠른 속도(최근글 보기에서 적절하게 인덱스를 쓸 수 있게 해서)를 위한 테이블에 데이터를 넣을 수 없거든요.
단지 빵구난 부분을 다시 구성하는 부분을 크론에서 돌 수 있도록 하면 안보이는 현상이 계속 지속되는것은 막을 수 있습니다.
크론이 한시간에 한번씩 돌게 하면 안보이는 시간이 최대 한시간이 되게 됩니다.
더 중요한건 제가 크론과 관련된 코드를 추가해야 하는데 ㅡ,.ㅡㅋ
흑...
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
아까 글올리기
아까 글올리기 테스트를 해봤는데 잘 올라가더군요. 중간에 글이 유실되는 현상은 거의 안 생길듯 합니다~
만약 문제가 되면 그때 가서 다시 고민하면 될 것 같구요. 크론 관련 코드를 추가해주실 수 있으면 좋겠지만 안되면 그냥 이대로 쓰고... 문제가 되면 다시 오리지널 tracker로 돌아가야죠 뭐. 그래도 뭔가 문제가 되면 tracker를 빼든가... ^o^
댓글 달기