편집 : 원래 게시물을 잘못 읽었습니다. 168 개의 모듈이 많으며 300 ~ 700ms의 SQL 쿼리가 엄청납니다 . 더 많은 모듈을 사용할수록 모듈이 일부를 수행하자마자 더 많은 쿼리가 수행됩니다.
공격적인 캐싱을 사용하고 가능한 경우 모든 것을 캐시하고 충분하지 않은 경우 리버스 프록시 캐시를 시도하십시오. 파일에 CDN을 사용하면 전체를 크게 향상시킬 수 있습니다. 리버스 프록시 캐시는 필요하지 않은 페이지를 방문 할 때 일부 인증 쿠키를 제거하여 도움을 줄 수 있습니다 (핵심은 사용자가 익명이라고 생각하고 캐싱을 최대화 함).
Drupal 코어 다이내믹은 너무 많은 모듈이 동시에 상호 작용하는 즉시 새벽 전체를 느리게 만듭니다.
예를 들어 필드를 사용하는 대신 hook_node_load () 시간에 데이터를로드하는 많은 모듈을 사용하는 경우 필드 사용이 캐싱 효율성을 보장하는 동안 많은 쿼리를 생성합니다.
렌더링에도 많은 시간이 소요될 수 있습니다. drupal_render () (언제나 렌더링 API라고도 함)는 API (실제로는 유용하지만)이지만 조각이 약간 느립니다. PDO (D7) 및 전체 DBTNG로 전환하면 무시할 수없는 대기 시간이 추가됩니다.
즉, 코어 자체는 매우 빠르지 만 (거의 아무것도 설치되지 않은 경우에도 너무 많은 SQL 쿼리를 수행함) 제대로 코딩되지 않은 모듈은 종종 병목 현상이 발생합니다.
APC는 실행되는 코드에 따라 2 또는 3마다 실행 시간을 나눌 수 있습니다. 잘 구성하면 (모든 APC 최적화를 사용할 수있게됩니다.) 공식 APC 매뉴얼은 잘 작성되어 있으며 귀하를 안내 할 것입니다.
느린 파일 시스템 (네트워크 파일 시스템 또는 느린 하드 드라이브)이있는 상자에있는 경우 실행 시간에 눈에 띄는 영향을 줄 수 있습니다. Drupal은 많은 작은 파일 로 만들어졌으며 , PHP는 FS가 파일을로드 할 때마다 FS에서 I / O를 수행하도록합니다 (APC도 많은 도움이됩니다).
잘못 구성된 DBMS는 MySQL을 사용하는 경우 미세 조정에 대해 생각하면 병목 현상이 발생할 수 있습니다. 공유 호스팅을 사용하는 경우 Drupal 관련 (또는 준비된) DBMS 및 PHP 스택이 아닌 경우 아마도 잘못 구성되거나 조정되지 않아 사이트 속도가 느려질 수 있습니다.
모든 캐시를 활성화하는 것을 잊지 마십시오. 사이트가 사용자 중심으로 인증되지 않은 경우 공격적인 페이지 캐싱을 활성화하십시오 (정말 훌륭합니다).
블록이 많을수록 전체 페이지가 느려지고, 뷰 모듈 모듈 블록은 가시성을 제한하지 않으면 사용하는 Views 플러그인에 따라 OG의 블록이 큰 고통이 될 수 있습니다. 페이지 단위로 또는 사용자 정의 PHP 코드를 사용하여 (다른 블록도 항상 블록 가시성을 수동으로 설정하고, 빈 블록을 렌더링하지 않도록하여 프레임 워크를 크게 도와줍니다).
hook_init ()를 사용하는 모듈을 피하십시오. 403 또는 404가 있어도 모든 페이지가 느려지더라도 (이미지 캐시 생성 시간이 느려지 며, 파일의 404 오류는 새벽은 천천히 파일이 존재하지 않는다고 알려줍니다).
