성능 로깅 모듈을 사용하고 있습니다. 위의 스크린 샷에서 모든 페이지에 Insert Cache_bootstrap이 있다는 이상한 점이 있습니다. 임의의 페이지 (관리자 테마 및 프론트 엔드 테마)로 이동하면 캐시 삽입 후 캐시 삭제가 실행 중입니다. 이는 캐시가 각 페이지에서 설정 및 소멸되고 실제로 캐시가 발생하지 않음을 의미합니다. 더 자세히 설명하려면 어떻게해야합니까? 현재 사이트 성능을 연구하고 있기 때문에이 문제를 진단합니다.
또한 성능 검사에 New Relic 을 사용하고 있습니다. 또한 데이터베이스로드가 높다는 것을 보여줍니다.
및 my.cnf 정보.
답변:
필자의 퍼포먼스 프레젠테이션 슬라이드 # 85 에서는 MySQL의 최대 패킷 크기에 대해 이야기하고있다. 그 가치를 높여야한다. SET GLOBAL max_allowed_packet=33554432;또는 구성 파일 https://dev.mysql.com/doc/refman/5.7/en/packet-too-large.html 에서 변경 하십시오.
허용되는 최대 패킷 크기가 이런 일이 발생하는 이유 일 수 있지만이 경우 다른 이유 일 수있는 여러 가지 이유를 볼 수 있습니다.
이 패턴의 가장 일반적인 이유는 모든 페이지에서 발생하는 variable_set () 호출입니다. xhprof를 사용하거나 xdebug를 사용하고 중단 점을 설정하거나 debug_print_backtrace (DEBUG_BACKTRACE_NO_ARGS)를 추가하여 캐시 삭제가 발생하는 위치를 살펴보십시오. 거기에 variable_set () 호출이 표시됩니다.
문제는 변수에 대한 단일 글로벌 캐시가 있다는 것입니다. 모든 캐시 쓰기는 캐시 삭제를 초래하며 다음 요청은 전체 {variables}테이블을 읽고 캐시에 다시 씁니다.
많은 개발자들은이를 인식하지 못하고 .module 파일 또는 모든 요청에서 실행되는 다른 위치에서 variable_set ()을 직접 호출하여 "값 보장"과 같은 작업을 수행하고 있습니다.
가설 일 뿐이지 만 부트 스트랩 캐시가 모든 페이지로드에서 재 구축되는 경우 일부 모듈이 모듈 폴더에는 없지만 시스템 테이블에는 여전히 존재할 수 있습니다. 각 페이지에서로드 drupal은이를 찾아 bootstrap_cache를 다시 작성합니다.
시도 부트 스트랩 최적화 모듈을, 그러한 기록을 찾아 삭제하는 데 도움이 될 것입니다.