저는 불당썸을 잘 이용하고 있는 NBA Mania라는 커뮤니티 운영자입니다.
현재 동시 접속자 수가 1000명 정도인 커뮤니티를 운영하고 있는데요,
이미지가 30개 정도 올라오면 썸네일을 생성하는데 시간이 상당히 오래 걸리며 서버 로드가 폭증하는(top load가 28~30까지 치솟음)는 문제가 있는데요, 이 것이 어떤 이유에선지는 모르겠지만 이 프로그램을 개발하신 불당님께서는 혹시 방법을 알지 않으실까 해서 이렇게 질문 드리게 되었습니다.
getimagesize 함수의 퍼포먼스 문제
제가 알아보니 http:// 등의 url 형태로 돼 있는 이미지를 getimagesize로 읽어드리면 이미지를 다운로드하기 때문에 시간이 많이 걸린다고 하는 것 같았습니다. 그래서 저희 서버로 업로드 돼 있는 이미지들만 썸네일 생성을 하게끔 불당썸을 수정 했습니다. 그래서 퍼포먼스가 좋아지긴 했습니다만 아직 완벽하진 않습니다. 원인이 getimagesize가 아닐 수도 있다는 이야기 같아요.
30장 정도의 이미지를 리사이즈해서 썸네일 생성한다고 쳤을 때 썸네일 생상에 수십초 정도가 걸리는데 워낙 활성 방문객이 많아서 이 시간 동안 수십명이 접속을 하게 되고 서버 로드가 폭증하게 돼서 서비스가 1~2분 정도 마비 됩니다.
해결책
썸네일 생성이 오래 걸리는 원인을 찾으면 좋겠지만 그러기 힘들거나(만약 아신다면 알려주세요) 원래 오래 걸리는 작업이라면, 대안으로 작성자는 자기 글을 꼭 확인할테니 작성자만 썸네일 생성을 할 수 있도록 하는 게 어떨까 생각해 봤습니다. 그렇게 하면 다수의 사용자가 썸네일 생성 명령을 내래지 않게 되고 서버 로드 폭증 문제를 막을 수 있다는 생각이 들었거든요.
어떻게 불당썸 프로그램을 수정하면 썸네일을 작성자만 생성하도록 할 수 있을까요? 프로그램이 워낙 복잡하고 방대해서 이렇게 개발자분께 직접 도움을 청하러 왔습니다.
긴 글 읽어주셔서 감사드리고, 도움 주실 수 있는 부분이 있으시면 도움 부탁드리겠습니다.
그부분은 솔직히 어찌할 수 없습니다.
불당썸의 자매품 resize를 보면 (b4.lib.php) 이미지 파일이 외부에 있을 때 처리하지 않게 하는 코드가 있습니다.
웹편집기로 올린 경우라면 resize를 이용하시면 그런 부분이 다 필터링 되기 때문에 편리합니다.
코드도 아주 간단 합니다. ㅎㅎ
resize_data( $view[wr_content] ) ;
===
// 이미지 파일의 경로를 설정 (외부? 내부? 내부인경우 절대경로? 상대경로?)
if (preg_match("/^(http|https|ftp|telnet|news|mms)\:\/\//i", $img['src'])) {
// 내 서버에 있는 이미지?
$img_src = @getimagesize($img['src']);
if (preg_match("/" . $_SERVER[HTTP_HOST] . "/", $img[src], $matches)) {
$url = parse_url($img[src]);
$img[src] = $url[path];
$thumb_path = "1";
} else {
return $return;
}
} else {
$thumb_path="1";
}
opencode의 배포 프로그램은 모두 쓰기 위해서 만든 것이고, 어느 부분은 H/W의 지원을 받아야 가능 합니다.
동접이 높은 상황에서 썸 때문에 접속이 힘들어진다면 HW 및 OS 설정을 정비 하시는 것이 필요한 시점입니다.
프로그램으로 해결 가능한 부분이 아니거든요.
1. swap을 보세요. swap이 사용되고 있다면 이미직 작업이 disk에서 일어나고 그런 이유로 늦어질 수 있습니다.
swap 보다는메모리가 사용될 수 있도록 OS를 설정해야 합니다.
2. 서버의 Disk IO 관리가 충분히 관리되고 있는지 보셔야 합니다.
작년에 HP만 5대를 신규로 넣었는데, 성능이 참 묘해서 금년초 전면적으로 Raid 부분을 정비하였습니다.
HP 등을 비롯해서 대부분의 시스템이 HDD의 write cache를 OFF 해두고 있습니다.
이경우는 이미지가 많지는 않지만, 심각할 정도의 속도지연은 없습니다.
HP DL120 G7 - 1대에서 돌아가는 경우 입니다. 동접은 지금 220 정도 입니다.
http://www.2cpu.co.kr/bbs/board.php?bo_table=sell&wr_id=38098
어떤 시스템 구성인지 모르겠지만,
그누보드의 경우 동접 200을 넘는 시점부터 신경써서 서버의 부하를 관리해줘야 합니다.
마지막으로 이미지의 문제 때문이 아닌, MySQL 등의 문제에서 기인했을 수도 있습니다.
속도라는 것은 단순히 함수나 그런거 몇개 개선으로 되는 것이 아닌 경우가 더 많거든요.
제 추정으로 현재의 문제는 disk i/o와 시스템 설정, mysql의 문제 입니다.
여유 메모리를 확보해서 한 번 운영해 보고 또 문제가 생기면 IO등을 살펴볼 수 있도록 하겠습니다.
근본 원인을 찾은 듯 싶네요. 빠른 답변 감사드립니다!
MySQL의 테이블이 myisam인 경우 disk의 쓰기 지연이 발생하면 모든 connection이 멈춰버립니다.
그리고 swap이 생긴다면 메모리보다 raid를 정비하는 것이 더 싸고 효과가 즉각적입니다.
write cache가 들어가는 경우 이런 상황에서 cache에서 처리되기 때문 입니다.
불당팩도 아닌데, 동접이 그정도면 상당히 관리를 잘 하시는 것 같습니다 ^^