mysql 쿼리 캐시

mysql 쿼리 캐시

QA

mysql 쿼리 캐시

본문

쇼핑몰 첫 화면이 로딩하는 데 너무 오래 걸려서, 제 추정으로는 mysql쿼리문제인 것 같아 그것에 초점을 맞추고 문제를 해결하고 있습니다.

 

그 방법 중의 하나인 쿼리캐시를 적용해봤는데, 솔직히 적용하고 나서 나아지긴 나아졌는데 사람들이 많이 들어올 때도 원활하게 접속이 될지는 아직 의문이네요..

 

 

본론 들어가겠습니다.

 

 

제가 my.cnf의 [mysqld]에 다음 소스를 추가했더니 

 

query_cache_limit=128M 

query_cache_size=512M 

query_cache_type=1 

 

다음과 같은 캐시 성능이 나옵니다.

 

Qcache_free_blocks            | 11814

Qcahce_free_memory         | 28351432

Qcache_hits                     | 11485779

Qcache_inserts                 | 590550

Qcache_lowmem_prunes    | 0

Qcache_not_cached          | 173854

Qcache_queries_in_cache   | 32908

Qcache_total_blocks         | 77689

 

(어떻게 해야하는지 잘 몰라서 값도 임의로 집어넣었고, 성능도 해석을 잘 못해 어려움을 겪고 있네요..ㅠㅠ)

 

아무튼, 쿼리 캐시 관련 공식 중에

 

Query Cache Hit Ratio = ( Qcache_hits / ( Com_select + Qcache_hits ) ) 

 

라는 공식이 있던데, show status를 통해 Com_select값을 조회해보면 1밖에 안되네요..?

 

그러면 제 쿼리 Hit Ratio값이 거의 100%에 수렴한다는 건데.. 이게 정상적인 건가요?

 

 

P.S) 디지털오션에서 그누보드영카트를 이용해 쇼핑몰을 운영 중이고, 서버 사양은 원래 CPU 8G에서 시작했는데 사이트를 운영할수록 첫화면 로딩문제가 너무 심각해지고 심할 때는 타임아웃까지 나버려서 32G까지 늘려놓은 상태입니다.

이 과정을 통해 제가 얻고자 하는 것은 "8G 정도의 CPU사양으로도 충분히 운영될 수 있는 서버사양을 만드는 것"입니다.

 

P.S2) 한 가지 제가 체감상 느끼는 특징을 하나 더 말씀드리면, 사이트에 접속할때 도메인으로 접속하는 것보다 아이피로 접속하는 것이 더 빠릅니다(클라우드플레어 서비스 이용중).

예를 들어, 서버의 도메인이 shopping.co.kr이고 이 도메인이 999.999.999.999라는 서버아이피를 향하도록 설정되어 있다고 하면 999.999.999.999로 접속할 때는 5초 정도 걸리는 것이 shopping.co.kr로 접속할 때는 5초보다 더 많이 걸립니다.

 

이 질문에 댓글 쓰기 :

답변 4

1. 전체 페이지를 저장함.

2. 그걸 보여줌

3. 페이지에서 변경되는 내용(새로 추가되는 레코드, 조회수, 날짜,.. 등)이 있으면 저장된 파일 삭제.

4. 파일이 없으면 다시 생성.

 

대강 이런 순서겠네요.

디비 연결 없이 html 파일로만 뿌리게 되니까 효과는 원더풀합니다.

제가 이해한 게 맞는지 모르겠네요.
예를 들어서
제 쇼핑몰에 "가오나시 인형"이라는 상품이 있고, 그 상품 페이지의 링크가
shopping.co.kr/shop/item.php?it_id=1 이런식이라고 하면,
현재는 이 링크를 goo.gl로 줄여서 외부사람들로 하여금 유입되도록 하고 있습니다.
그런데 태엽님께서 말씀하신것은

1. 이 페이지를 통째로 html문서로 저장한다.
2. 이 html문서를 저장한 주소를 shopping.co.kr/shop/item1.html로 지정한다.
3. html문서의 링크를 goo.gl.로 줄여서 외부사람들로 하여금 유입을 시킨다.
4. 원본 문서인 php페이지에 변경사항이 생기면, 새로 html문서로 저장하여 기존의 html문서를 대체한다.

이게 맞나요?

html로 저장하라는 의미는 웹서버에서 웹브라우저로 출력하는 최종 output을 별도로 저장하라는 의미인 것 같습니다.

그것이 꼭 html 확장자를 가지는 파일일 필요는 없고 단지 웹브라우저로 내보내는 데이터의 양식이 html이기 때문에 html로 저장하는 것입니다.

이것은 클라이언트와는 전혀 무관하고 오로지 웹서버의 내부적인 동작에만 관련되어 있습니다.

일반적으로 데이터베이스에서 데이터를 가져와서 가공을 하고 이것을 html 태그들과 함께 조합한 결과를 생성하는데, 이 결과를 저장하는 것이 html 캐싱입니다. 따라서 데이터 조회 및 가공 과정이 생략될 뿐이지 최종 html을 출력한다는 점에서는 다르지 않습니다.

도움이 되셨기를 바랍니다.

경험상 쿼리로 해결되진 않습니다.

페이지 전체를 캐시 파일로 저장하는 방법이 가장 확실합니다.

물론 내용 변경이 있다면 바로 캐시를 삭제하고 다시 저장하는 방식으로 해야겠지요.

데이터베이스에서 데이터를 가져오는 게 느리다면 쿼리분석을 통해 쿼리 튜닝(슬로우 쿼리 제거, 인덱스 사용 등)을 하는 쪽이 장기적으로 봤을때 유리합니다.

쿼리 캐싱이든 페이지 캐싱이든 캐싱이라는 것 자체가 정보의 갱신이란 측면에서 취약할 수밖에 없습니다. 때문에 주기적으로 또는 데이터 입력, 삭제, 수정 등의 활동에 따라 다시 캐싱을 하는 추가적인 작업이 필요합니다.

쿼리 튜닝을 먼저 수행하고 거기에 각종 캐싱을 더하면 더욱 확실한 해결책이 되지 않을까 생각합니다.

네 맞네요.

중요한 건 출력되는 페이지에 변동사항이 생기면

즉시 파일을 삭제하고 새로 저장하면 된다는 것.

저장하는 타이밍은 파일 삭제 후 첫 접속자겠죠. 

답변을 작성하시기 전에 로그인 해주세요.
전체 7
QA 내용 검색

회원로그인

(주)에스아이알소프트 / 대표:홍석명 / (06211) 서울특별시 강남구 역삼동 707-34 한신인터밸리24 서관 1404호 / E-Mail: admin@sir.kr
사업자등록번호: 217-81-36347 / 통신판매업신고번호:2014-서울강남-02098호 / 개인정보보호책임자:김민섭(minsup@sir.kr)
© SIRSOFT