속도저하에 따른 일부 서비스 잠정 중단....
본 geekforum의 방문자가 늘어나고, 다양한 주제에 대해 답글이 증가하면서 웹사이트의 반응/처리 속도가 대단히 늦어졌습니다. 따라서 현재 처리 속도를 증가시킬 수 있는 방안을 찾고 있는 중이며 오른쪽 블럭에서 제공되던 "뉴스 생중계" 기능이 속도 저하에 상당한 영향을 미친다는 의견이 있어 테스트를 위해 잠시 "뉴스 생중계"를 중단합니다.
"뉴스 생중계"는 어느정도 테스트가 끝난 뒤에 복구 여부를 결정하도록 하겠습니다.
속도 저하 문제는 사실 상당히 심각합니다. 답글이 2-30개가 넘어갈 경우 페이지가 로딩되는데 아주 오랜 시간을 기다려야 한다는 사실을 잘 알고 계실 것입니다. 그러므로 이 문제에 대해 여러분의 도움이 절실히 필요합니다. 본 사이트는 http://weblog.kldp.org 에서 개발되고 있는 KorWeblog를 기반으로 제작되어 있으므로 본 사이트에서 사용 중인 소프트웨어의 소스코드를 입수/분석하고자 하는 분은 http://weblog.kldp.org 를 방문해 보시기 바라며 속도저하에 관련된 문제점 및 기술적인 분석 결과는 왼쪽 블럭의 "특집 기사"섹션이나 http://weblog.kldp.org 에 글을 올려 주시기 바랍니다.
KorWeblog는 GPL하에 공개되는 자유 소프트웨어이므로 누구나 개발에 참여하실 수 있습니다.
KorWeblog의 속도 향상에 획기적인 도움을 주시는 분께는 감사의 뜻으로 선물(?)을 드리도록 하겠습니다. 자세한 사항은 역시 왼쪽의 "특집 기사"를 참고하십시오.
댓글
여하튼 운영하시느라 수고하시는데요 저는 잘 모르니 잘되기만을 바랄께요
여하튼 운영하시느라 수고하시는데요 저는 잘 모르니
잘되기만을 바랄께요.
안녕하세요? 오른쪽에 있던 뉴스생중계에 관한생각인데요.저의 홈페이
안녕하세요? 오른쪽에 있던 뉴스생중계에 관한생각인데요.
저의 홈페이지(http://linuxfactory.org)의 경우에는
1시간 간격인데요. 캐시파일의 생성을 도와주기위해 크론탭으로 아래의 명령을 수행해줍니다.
lynx --dump http://linuxfactory.org
안해주는 것 보단 효과가 좋던데욥.
그럼.
소프트웨어로 구현하는 트랜직션도 한계가 있습니다kldp에 디비퀴리
소프트웨어로 구현하는 트랜직션도 한계가 있습니다
kldp에 디비퀴리로 볼떄 당연한 결과입니다
그만큼 엄청난 퀴리가 있다는 증거이겠고
현재 korweblog퀴리방식은 저에 허접생각엔
해당쓰래드가 많아지면 당연히 느려지겠죠....
한번에 퀴리로
모든쓰래드테이블를 처리해야하는방식아닌가요?
이떄 헌데 kldp서버에 자료는 여기 토론장뿐만 아니라
각종 번역문서들등등 많은 접속자가 다른퀴리도 요구하는데
어쩔수 없이 스케줄링에 총제적인 지연도 있를꺼고 ...
이런문제에 극복은 어쩔수 없는 하드웨어에 지원뿐이라고
생각합니다...
P/S 저는 느리다고 생각하지 않습니다...
접속자가 많아서 지연되는 문제인데 어쩔수 없고
아마 욕하는분들도 없를겁니다.
방금 심심해서 알아보니kldp.org geekforum.k
방금 심심해서 알아보니
kldp.org
geekforum.kldp.org
서브도메인으로 별도서버로 운영되고 있군요...
----
이떄 헌데 kldp서버에 자료는 여기 토론장뿐만 아니라
각종 번역문서들등등 많은 접속자가 다른퀴리도 요구하는데
어쩔수 없이 스케줄링에 총제적인 지연도 있를꺼고 ...
----
그럼 위에서 말한 저에 내용은 전혀 관계가 없다는문제인데
그렇담 geekforum.kldp.org 서버는 여기토론장 전용디비
형태로만 운영되는거 같은데요..
음 그럼 일단하드웨어 업에대한 문제는 차후에 문제인거
같습니다.
기존의 게시판에서는 전체 글을 화면을 나누지 않고 답변과 해당게시판의
기존의 게시판에서는 전체 글을 화면을 나누지 않고
답변과 해당게시판의 게시물을 전체를 화면에 뿌려주기 때문에 문제가 있는것 같은데..
일단 페이별로 구분지어서 화면에 뿌리는 방식을 쓰면
처음 해당게시판의 게시물을 보여줄때, 처음 페이지를 보여주고 , 다음 페이지를 선택했을때, 다음 페이지에 해당하는 내용만 DB에서 꺼내오는 방식을 하면 어느정도 속도저하를 해결할수 있을것 같은데요..
제가 잘 파악은 하지 못하는 것일수도 있지만...게시판의 부하 문제는
제가 잘 파악은 하지 못하는 것일수도 있지만...
게시판의 부하 문제는 php 스크립트 언어의 성능에도 관계가 있지 않을까요?
하나의 스크립트를 돌릴때마다 하나의 번역기가 돌아가야 하니... 접속이 폭주하면 엄청나게 많은 번역기가 돌아갈테고.. 스크립트의 실행속도가 떨어지는 그런 현상일수도 있지 않을까요?
그냥 추측이고요...
일단 임시로 페이지 최상단에 KLDP의 뉴스 생중계 페이지로의 링크를 추
일단 임시로 페이지 최상단에 KLDP의 뉴스 생중계 페이지로의 링크를 추가하였습니다. 제가 보기에는 속도 차이가 확연히 나는데 뉴스 생중계는 그냥 이런 식으로 처리해 버릴까 합니다.
SCSI로의 전환을 고려해 보시길...
SCSI로의 전환을 고려해 보시길...
하드웨어를 교체하는 것으로는 한계가 있습니다. 지금 필요한 것은 그런게
하드웨어를 교체하는 것으로는 한계가 있습니다. 지금 필요한 것은 그런게 아니라 실제 웹사이트를 돌리고 있는 소프트웨어의 개선점을 함께 찾아보자는 것이지요.
아마도 SCSI 같은 장비가 사용할 형편이 안되서 어렵다는게 아닐지요.
아마도 SCSI 같은 장비가 사용할 형편이 안되서 어렵다는게 아닐지요.
누가 하나 던져주고 가면 당연히 쓸듯.
Anonymous wrote...
> SCSI로의 전환을 고려해 보시길...
물론 장비를 SCSI로 바꾸면 당장은 효과가 있겠죠현재 답글이 2
물론 장비를 SCSI로 바꾸면 당장은 효과가 있겠죠
현재 답글이 20~30개 정도면 버벅 거린다고 하셨는데
스카시 장비로 바꾸면 30~40개 정도로 늘어날
수는 있겠죠
하지만 이게 근본적인 문제는 아닌거 같습니다.
답글이 50개가 넘어가 버리면 그 때는 어떻게
대처를 하실꺼죠?
그 때 가서도 님은 하드웨어를 증설하라고 하시겠죠?
서버를 늘리고 로드밸렁싱을 하고...
캐싱 서버를 두고.......
이건 한도 끝도 없겠죠....
댓글 달기