골치가 아픕니다. 정보
골치가 아픕니다.
본문
G4 기반에 예전에 아빠불당님께서 감사하게도 만들어서 공개해주신 카페 플러그인을 탑재해서
커스터마이징해서 만든 사이트가 있습니다.
그전에는 일반 날코딩으로 만들어졌던 게시판 위주의 사이트 였는데, 게시판당 DB테이블을 1개씩 썼는데,
카페기능 비스므레 하게 만들다보니 DB테이블이 2천개가 넘어가자 DB가 버벅버벅~
그래서 카페 플러그인을 커스터마이징해서 슬림하게 잘 만들었습니다.
카페 플러그인이 iframe 방식으로 개발되서 요즘 브라우저나 태블릿에서 문제가 많아서 여기에 모바일을 붙히고 리뉴얼을 해야하는데...
갑갑하네요~
G5에 카페 플러그인을 만들어서 이전해야 하나... 일이 너무 커지는데...
그정도 견적을 받을수는 없을거 같고... 여러가지 일이 얽혀있는데라 해주기는 해야하고...
머리가 아픕니다~
이걸 해결할 만한 한방팩~은 없겠지요~? ㅋ
공감
0
0
댓글 19개
카페가 2000개나 된다는 말씀인가요?
저도 앞으로 풀어야할 숙제중에 하나인데..
적당한 규모별로 독립시켜야 하지 않을까 싶네요..
저도 앞으로 풀어야할 숙제중에 하나인데..
적당한 규모별로 독립시켜야 하지 않을까 싶네요..
아뇨... 카페는 한 50개 정도 되는데 카페별로 게시판이 한 10~20개 정도 쓰거든요.
카페 플러그인 적용해서 지금은 테이블이 한 200개 정도로 줄여놨어요.
카페 플러그인 적용해서 지금은 테이블이 한 200개 정도로 줄여놨어요.
DB(SQL), 프로그램 튜닝, 서버 확장 ....
+1 ㅋㅋㅋ
아참 디자인은 벤지님에게 ㅋㅋㅋ
아참 디자인은 벤지님에게 ㅋㅋㅋ
카페 플러그인이 iframe 방식이라 이걸 걷어내려면 플러그인 전체를 손봐야 하는데... 구조는 대충 파악하고 있지만 작업하기는... 분량이 많아서... ㅠㅠ
"짜가 디자이너" 인사 드립니다....ㅋㅋㅋ
동시사용자수가 많은건 아니라서 (회원은 많지만) 확장이나 튜닝이 필요한 건 아니구요. 다만, 상단, 좌측메뉴, 본문(iframe), 하단 구조로 되어있는걸 One 페이지 구조로 변경해야 하는데 그 작업이 귀찮고 번거로운 거죠.
UI 로 판단하시는것보다
어느쪽이 문제인지 ( DB 쪽이냐, 웹서버쪽이냐 ) 찾아 보시는게
더 빠르실듯합니다.....
어느쪽이 문제인지 ( DB 쪽이냐, 웹서버쪽이냐 ) 찾아 보시는게
더 빠르실듯합니다.....
문제가 UI 입니다. ㅋㅋㅋ
본문내용에 따라서 리사이징 스크립트가 잘 안먹는 경우가 종종있고, 뭐 그런 저런 이유들이구요.
모바일웹도 도입해야 하는데 겸사겸사 G5 로 업그레이드를 하자니 카페 플러그인이 걸리고... .
본문내용에 따라서 리사이징 스크립트가 잘 안먹는 경우가 종종있고, 뭐 그런 저런 이유들이구요.
모바일웹도 도입해야 하는데 겸사겸사 G5 로 업그레이드를 하자니 카페 플러그인이 걸리고... .
스크립트가 잘 실행 않되는 경우중에 서버에서
css 나 js, img 을 빨리 내려 받지 못해 UI 쪽에서 에러가 난것처럼 느낄때도
있습니다.
그런데 본글은 "2천개가 넘어가자 DB가 버벅버벅" 인데,
UI 쪽에 문제라고 하시면 ...
다른분에게 패스할께요.....건투을 빕니다.
css 나 js, img 을 빨리 내려 받지 못해 UI 쪽에서 에러가 난것처럼 느낄때도
있습니다.
그런데 본글은 "2천개가 넘어가자 DB가 버벅버벅" 인데,
UI 쪽에 문제라고 하시면 ...
다른분에게 패스할께요.....건투을 빕니다.
테이블이 2천개가 넘어가서 DB가 버벅버벅 해서
(아빠불당님께서 만들어주신) 카페 플러그인을 사용해서 슬림하게 커스터마이징 했습니다. - 가 한 7년전 이야기 입니다.ㅋ
(아빠불당님께서 만들어주신) 카페 플러그인을 사용해서 슬림하게 커스터마이징 했습니다. - 가 한 7년전 이야기 입니다.ㅋ
제가 사용한 방법중 하나
1) Innodb 로 변경 ( Record Lock )
2) 게시판의 자동 증가 값 변경
3) DB 튜닝 ( http://cyller.tistory.com/5 <-- 더 깊게 계산해야 합니다 )
4) Query 튜닝
5) Slow Query 찾아 ( 3~5 sec 이상 )서 변경
6) Apache 데몬 튜닝
7) 이래도 않되면 DB 서버 또는 웹서버 분리 ( 부하가 많은 서버 위주로 확장 )
잘되면, 머리카락 빠진 머리를 보게 되고
않되면
버려야 합니다...라고 상부에 보고....~~
1) Innodb 로 변경 ( Record Lock )
2) 게시판의 자동 증가 값 변경
3) DB 튜닝 ( http://cyller.tistory.com/5 <-- 더 깊게 계산해야 합니다 )
4) Query 튜닝
5) Slow Query 찾아 ( 3~5 sec 이상 )서 변경
6) Apache 데몬 튜닝
7) 이래도 않되면 DB 서버 또는 웹서버 분리 ( 부하가 많은 서버 위주로 확장 )
잘되면, 머리카락 빠진 머리를 보게 되고
않되면
버려야 합니다...라고 상부에 보고....~~
innodb는 현재 업그레이드 할때 생각하고 있고(현재 DB가 4.0 이라 리뉴얼할때 5.x 로 업그레이드 예정입니다.)
나머지는 뭐 대충 서버 셋팅할때 체크하고 있습니다만...
실제 트래픽은 많지 않아서 크게 문제가 되진 않습니다.
Mysql DB가 4.x 에서는 DB 테이블수가 2000개가 넘어가면 갑자기 엄청 느려지더라구요.
나머지는 뭐 대충 서버 셋팅할때 체크하고 있습니다만...
실제 트래픽은 많지 않아서 크게 문제가 되진 않습니다.
Mysql DB가 4.x 에서는 DB 테이블수가 2000개가 넘어가면 갑자기 엄청 느려지더라구요.
지금까지 작성하신 내용으로만 파악하는건 위험하지만
트래픽 문제가 아니라, DB 쪽의 Table Lock 문제와
Query 가 사용하는 메모리 사용량의 설정 문제가 아닌가 싶습니다.
트래픽 문제가 아니라, DB 쪽의 Table Lock 문제와
Query 가 사용하는 메모리 사용량의 설정 문제가 아닌가 싶습니다.
조언해주셔서 감사합니다.
DB가 느려서 문제가 됐던건 옛날의 문제였고.
지금은 본문이 iframe 구조로 되어있는 카페 플러그인을 One 페이지로 만드는게 문제의 핵심입니다. ㅋ
DB가 느려서 문제가 됐던건 옛날의 문제였고.
지금은 본문이 iframe 구조로 되어있는 카페 플러그인을 One 페이지로 만드는게 문제의 핵심입니다. ㅋ
제가 너무 옛날얘기부터 꺼내서 내용에 혼동을 드렸던것 같습니다.
이자리를 빌어 사죄의 말씀을 올리겠습니다. (__)
이자리를 빌어 사죄의 말씀을 올리겠습니다. (__)
저 딱딱한 사람 아니예요....ㅠ_ㅠ
해결 해야 하시는 입장에서 얼마나 고달프실지 느껴서
몆자 적은건데, 사죄 말씀 드려요...(ㅡㅡ)(_ _)
iframe 구조는 정확하고 확실한 방법을 아는게 없어서...ㅠ_ㅠ
해결 해야 하시는 입장에서 얼마나 고달프실지 느껴서
몆자 적은건데, 사죄 말씀 드려요...(ㅡㅡ)(_ _)
iframe 구조는 정확하고 확실한 방법을 아는게 없어서...ㅠ_ㅠ
사이트 구경시켜 주세요 ㅎㅎ
폐쇄사이트 입니다~ ㅋ
