Minelli 하위 테마가 포함 된 D7 사이트를 구성했습니다. 그 과정에서 다른 주제와 다른 모듈을 많이 실험했습니다. 어딘가에서 나는 이상한 성능 문제를 개발했으며 이제는 테마 / 모듈 / 구성이 어떤 원인인지 알 수 없습니다.

문제는 사이트를 처음 방문 할 때 첫 페이지가 표시되기까지 약 15 초가 걸린다는 것입니다. 그런 다음 사이트를 이동할 수 있으며 반응이 매우 빠릅니다. 한 시간 정도 그대로두면 다시 돌아 오면 첫 번째 요청이 다시 매우 느립니다.

캐시가 지워서 문제가되지 않아야합니다. 또한 사용하지 않는 테마 및 모듈을 비활성화했습니다. 사이트를 새로운 인프라로 옮겼지만 문제가 발생했습니다!

다음에 어디로 가나 요?

내가 확인해야 할 세 가지가 있습니다.

하나는 프로덕션 사이트에 있고 PHP 파일을 편집하지 않는 경우 APC가 활성화되어 있고 메모리가 충분하며 긴 TTL이 있는지 확인해야합니다 (원하는 경우 하루가 지날 수도 있고 만료되지 않을 수도 있음). 설정을 고려할 수도 있습니다 apc.stat=0. APC의 문서는 당신이 TTL 설정에 필요한 모든 정보를 가지고있다. 메모리 양을 선택하려면 apc.php 파일을 보호 된 곳에 고정하고 메모리 사용량 및 이탈 통계를 모니터해야합니다. 미스율이 매우 낮도록 APC 메모리를 조정하십시오. 초기 속도 저하는 APC가 가득 차서 비워지기 때문일 수 있습니다 (IIRC, APC는 LRU 또는 고급 캐시 전략을 사용하는 대신 가득 차면 전체 캐시를 덤프 함).

둘째, MySQL을 적절히 조정했는지 확인하십시오. mysqltuner 를 사용 하여 버퍼 크기를 조정할 수 있습니다 . 디스크 및 / 또는 쿼리 캐시 누락에서 테이블을로드하기 때문에 초기 속도가 느려질 수 있습니다. 완벽하지는 않지만 mysqltuner는 올바른 방향으로 나아가도록합니다.

셋째, 실제 Drupal cron 전략 이 있는지 확인하십시오 . 개인적으로 "admin / config / system / cron"에서 autoron cron을 비활성화하고 매일 밤 실행되도록 crontab을 설정했습니다. 사물에 대한 세밀한 제어가 필요한 경우 Elysia Cron을 사용해 볼 수도 있습니다 . 이렇게하면 필요한 작업을 필요한만큼 자주 실행할 수 있지만 정상적인 작업은 밤새 실행됩니다. 매 시간마다 발생하는 크론 실행으로 인해 초기 속도가 느려질 수 있습니다. cron이 "admin / reports / dblog"에서 실행될 때를보고 느려짐과 일치하여이를 확인할 수 있습니다.

Ivanhoe123이 옳을 것입니다 : Drupal 7에는 기본적으로 'poor mans cron'이 활성화되어 있습니다. 즉, Drupal이 페이지를 렌더링하기 전에 cron이 (한 번에) 실행되어 모든 것이 지연됨을 의미합니다.

항상 생산 현장에서 실제 크론 작업을 사용하십시오. 자세한 기술 정보는 http://drupal.org/cron을 참조 하거나 호스팅 회사에 문의하십시오.

비활성화하려면 admin / config / system / cron으로 이동하여 'Never'를 선택하십시오.

(STABLE) 당신이 어떤 오래 실행되는 쿼리가 있는지 여부를 모듈 이벤트 데이터베이스 로깅을 확인합니다.

이것이 도움이되지 않으면 XHProf 또는 XDebug를 가져 와서 유죄 코드를 찾으십시오. XHProf (프로파일 러)는 서버에서 실행중인 모든 기능에 대한 멋진 맵을 제공하며 어떤 기능이 가장 많은 실행 시간을 소비하는지 알려줍니다. 반면 XDebug (디버거)가 Eclipse와 같은 IDE로 구성되어있는 경우 ( video 참조 ) LIVE에서 실행중인 모든 기능을 드릴 다운 할 수 있습니다. 프로파일 러는 당신의 아이디어를 줄 것이다 무엇을 실행 중입니다; 디버거가 왜 실행되고 있는지 보여줄 것 입니다.

질문의 맛에서 나는 즉시 세 가지를 생각합니다.

• MySQL 스토리지 엔진 / CPU
• 데이터베이스 캐싱
• 테이블 잠금

MySQL 스토리지 엔진

FULLTEXT 검색 / 인덱싱을 사용하지 않는 경우 모든 MyISAM 데이터를 InnoDB로 변환하는 것이 좋습니다. MyISAM은 여러 CPU와 여러 코어를 활용하도록 설계되지 않았습니다. InnoDB는 다중 CPU 사용 및 읽기 / 쓰기 하이퍼 스레딩을 위해 크게 향상되었습니다.

다음은 DBA StackExchange 및이 사이트에서 InnoDB 성능을위한 MySQL 조정과 관련하여 작성한 일부 게시물입니다.

• Sep 20, 2011: 멀티 코어 및 MySQL 성능
• Sep 12, 2011: MySQL에서 하나 이상의 코어를 사용할 수있게 함
• Jun 07, 2011: MyISAM에서 InnoDB로 데이터베이스를 어떻게 변환합니까?
• May 26, 2011: 단일 스레드 및 다중 스레드 데이터베이스 성능 정보
• Apr 15, 2011: https://drupal.stackexchange.com/questions/1715/what-would-be-the-optimal-mysql-configuration-for-a-drupal-7-site/2367#2367

데이터베이스 캐싱

모든 MyISAM 데이터를 InnoDB로 변환하는 또 다른 강력한 주장은 MySQL이 데이터 / 인덱스를 캐시하는 방법입니다. MyISAM 스토리지 엔진은 인덱스 만 캐시합니다. InnoDB는 데이터와 인덱스를 캐시합니다 . 이에 비추어 InnoDB 버퍼 풀에 다음 중 하나를 수용 할 수있는 충분한 메모리를 할당 할 수 있습니다.

• 모든 InnoDB 데이터 및 인덱스 (OS에 충분한 RAM이있는 경우 이상적이며 후속 지연을 제거함)
• 설치된 RAM의 75 % (RAM보다 많은 InnoDB 데이터 / 인덱스가있는 경우 지연 최소화)

MySQL 5.1을 사용하는 경우 innodb_max_dirty_pages_pct = 0을 설정할 수 있습니다. 이렇게하면 디스크 I / O가 약간 증가하지만 InnoDB 버퍼 풀은 디스크 I / O 서지없이 오래된 데이터 및 인덱스 페이지가 회전 할 수있을 정도로 지워집니다. MySQL 5.5 및 MySQL 5.1의 InnoDB 플러그인에는 더 나은 기본 버퍼 풀 플러싱 메커니즘이 있으므로이 조정이 필요하지 않습니다.

InnoDB를 사용하는 것이 문제가 아닌 경우 memcached 또는 varnish를 사용해야합니다. 이를 통해 개발자는 캐시 된 데이터가 서버 RAM에 얼마나 오래 있을지를 지시 할 수 있습니다. 당연히 이것은 애플리케이션을 memcached / varnish-aware로 만들기 위해 개발 향상이 필요합니다.

테이블 잠금

• InnoDB는 행 수준 잠금을 수행하여 트랜잭션 및 비 블로킹 읽기를 허용합니다 .
• MyISAM은 모든 INSERT, UPDATE 및 DELETE에 대해서만 전체 테이블 잠금을 수행합니다 .

발문

MySQL 재시작 후 초기 지연을 피할 수 없습니다. 그러나 위에서 언급 한 제안 / 정보를 사용하여 MySQL을 향상시킨 후에는 더 이상 후속 지연이 발생하지 않습니다.

YSlow 또는 Firebug 등과 같은 도구를 사용하여 해당 페이지를로드 할 때와 직후에 해당 페이지를로드 할 때 발생하는 상황을 정확하게 결정합니다. 캐싱 문제인지 확인하고 익명 사용자와 인증 된 사용자로 페이지에 액세스 할 때 페이지가 어떻게 작동하는지 확인하십시오. 이것을 Drupal의 성능 설정과 비교하십시오.

캐싱 문제가 아닌 경우 Devel의 쿼리 로그와 MySQL의 로그를 사용하여 데이터베이스에서 발생하는 상황을 확인하십시오. 또한 서버에 opcode 또는 이와 유사한 성능 향상 캐시가있는 경우 몇 가지 숫자를 가져 와서 다시 시도하십시오.

크론이 작동하는 것처럼 들립니다.

여기에서 설정을 확인하십시오 : admin / config / system / cron

이 때문에 마지막 프로젝트에서 Drupal을 거의 중단했습니다.

그래도 하나 이상의 원인이 있어야합니다. 이 문제가 발생할 때마다 작동하는 '모두 수정'솔루션을 아직 찾지 못했습니다.

Syslog 및 Ubuntu / Debain

간헐적 인 15 초로드 시간을 처음으로 실행 한 것은 (전용, 비공유) Debian / Ubuntu 기반 시스템에서 drupal을 실행하는 동안이었습니다. Syslog 모듈 을 비활성화하는 것이 저에게 해결책이었습니다.

@BetaRide가 말했듯이 xDebug 또는 다른 PHP 프로파일 러를 사용하는 것은 매우 밝습니다.

여전히 문제-해결 방법

다른 설치에 관해서는 여전히 손실이 있습니다.

이 문제는 개발 서버 및 트래픽이 적은 Drupal 설치에서 더 두드러집니다.

해결 방법으로 60 초마다 사이트 홈 페이지를로드하고 300 초마다 Drupal의 cron 스크립트를로드하도록 cron 작업을 설정했습니다. 이것은 분명히 최적은 아니지만, 인간 방문자 대신 15 초의로드 시간을 경험할 수 있습니다.

많은 사람들은이 문제가 관련이있을 수있는 제안 동기 백그라운드 프로세스 차단 특히 관련, 무거운 cron 작업을 .

사실이라면 gielfeldt에 의해 활발히 개발중인 훌륭한 모듈 쌍이 존재합니다. *이 문제를 바로 잡을 수도 있고 최소한 단서를 제공 할 수도 있고 사이트 제작자가 사례에 따라 특정 범인을 진단하고 치료할 수 있습니다. 둘 다 동기식 프로세스 차단을 비 블로킹 비동기 HTTP 또는 명령으로 대체하고 문제가있는 프로세스를 식별 할 수있는 관련 보고서를 제공합니다.

• 백그라운드 프로세스 및 번들 모듈을 사용하면 Drupal의 백그라운드 프로세스 큐를 비동기식으로 처리 할 수 ​​있으므로 차단되지 않습니다. 이로 인해 문제가 중지 될 수 있습니다. 또한 최신 개발에 번들로 제공되는 백그라운드 프로세스 Apache Server 모듈을 사용하면 이러한 프로세스의 시작 시간과 진행 상황을 감독, 잠금 해제 및 검사하는 기능을 갖춘 기본적이지만 개선 된 UI 보고서가 있습니다. 이는 문제점 프로세스를 식별 할 수 있습니다.
• Ultimate Cron 은 백그라운드 프로세스를 기반으로 구축되어 Cron 에서 트리거 된 작업에 별도의 비동기식 scehdules이있을 수 있으며 각각 UI에서 모니터링 및 중지 할 수 있습니다. 정기적 인 오버 헤드 오버 헤드 정리에서 헤비 듀티 성능 저장 작업을 분리하는 데 유용 할뿐만 아니라 각 개별 크론 트리거 작업의 실행 시간, 마지막 실행 시간, 현재 상태, 이것은 또한 문제 프로세스로부터 차단을 제거 및 / 또는 식별 할 수있다.

둘 다 어쨌든 매우 유용한 모듈입니다. 이 문제의 경우 동기식 블로킹 프로세스 또는 크론 실행으로 인해 블로킹이 발생한다는 (매우 타당한 사운 딩) 이론을 테스트하는 데 사용할 수 있습니다. 잠재적으로 이들은 동기식 대신 비동기식으로 이러한 문제를 해결함으로써 문제를 해결할 수 있으며 잠재적으로 어떤 프로세스가 중단을 유발했는지에 대한 단서를 제공 할 수도 있습니다. (그들의 문서는 매우 진행중인 작업임을 경고합니다 ...

그러나 전혀 도움이되도록 구성 할 수없는 경우 동기 백그라운드 프로세스보다 더 많은 문제가 있음을 나타냅니다. FWIW, 나는이 모듈이 제대로 작동하기 때문에 사이트 에서이 특정 문제를 경험하지 못했습니다.

또한 현재 개발중인 다른 관련 플러그인 모듈을 알고 있어야합니다 (예 : 복잡한 고강도 사례에서 임계 값 기반 스로틀을 허용하는 Ultimate Cron Queue Scaler 는 cron 관련 성능 문제를 줄이는 데 도움이 될 수 있음).

* 제휴 없음, 나는 그들의 작업에 대한 매우 인상적인 사용자입니다.

이것이 다시 한번 나에게 타격을 가하고 있기 때문에 문제를 조사하기 시작합니다. 나는 확실히 확인할 수 있습니다

1. drupal_cron_run()가난한 사람의 핵심 크론에 의해 호출되면 개발자 컴퓨터의 요청 시간에 ~ 5 초가 추가됩니다. 이것은에 호출 주위에 테스트를 주석을 테스트 할 수 drupal_cron_run()있는 modules/system/system.module에system_run_automated_cron()
2. 모든 캐시를 지우면 개발자 컴퓨터의 요청 시간에 ~ 2가 추가됩니다. drush cc all페이지를 다시로드하고 다시로드하여 테스트 할 수 있습니다 .

즉, cron을 절대로 설정하지 않고 crontab을 통해 cron에 호출을 추가하면 상황이 훨씬 좋아집니다. 캐시를 리필하기 위해 자주 사용되는 일부 페이지를 바로 치면 사용자 경험이 다시 악화 될 수 있습니다.

캐싱에 대해서는 확실하지 않습니다. 이 사이트의 기본 캐시 설정을 건드리지 않았습니다. drupal은 때때로 cron에 의해 트리거 된 모든 캐시를 재구성한다고 생각하지만 이것이 어떻게 수행되는지 잘 모르겠습니다. 그러나 7 초 지연은 몇 시간 후에 페이지를 방문했을 때 볼 수있는 것입니다.

이와 같은 문제는 문제를 일으킬 수 있으며 비슷한 상황에 있었을 때 문제가 한 번에 한 단계 씩 진행되는 원인을 파악한 다음 익명의 로그 사용자로 테스트하는 데 도움이됩니다. (양파 층법)

당신은 몇 가지 테마로 연주하고 자신만의 코딩을 한 후에 문제를 알기 시작한다고 언급했습니다. 귀하의 사이트와 그 배후의 논리가 얼마나 복잡한 지 잘 모르겠지만 다음 단계를 수행하면 문제를 찾는 데 도움이됩니다.

1. 서버에서 귀하의 사이트에서 사용중인 것과 동일한 버전으로 Drupal을 새로 설치할 폴더 또는 다른 계정을 작성하십시오 (이것이 더 나을 수도 있음). 그런 다음 모듈이나 테마 테스트를 추가하지 않고 사이트가 첫 번째 요청과 다음 요청에 응답하는 데 걸리는 시간. 모든 것이 제대로 작동하면 서버 구성 문제를 무시할 수 있습니다. 현재와 동일하게 작동하면 웹 서버 또는 데이터베이스에 구성 오류가있는 것입니다.

2. 1 단계의 결과가 양호하고 서버가 빠르게 응답하고 다음 요청이 빠르면 현재 사이트의 테마 만 새로 설치 사이트에 설치 한 후 다시 테스트하십시오. 모든 것이 여전히 빠르게 반응한다면 테마는 문제가 아니며 3 단계를 계속해야합니다. 그렇지 않으면 테마 디버깅을 시작해야합니다 * 1.

3. 2 단계에서 테스트 한 후에도 사이트에서 여전히 현재 사이트의 모듈을 가져 오기 시작하고 각 모듈을 추가하고 활성화 한 후 응답 시간을 테스트해야합니다 * 2.

4. 테마 및 모듈을 추가 한 후에도 사이트가 여전히 빠른 응답으로 구성 추가를 시작하고 컨텐츠 유형 작성,보기 가져 오기, 설정 메뉴 등을 수행하는 경우 각 사이트 추가 후 사이트 응답을 테스트하는 것을 잊지 마십시오.

5. 설정 및 구성 준비가 완료되었으며 사이트가 여전히 빨라 졌으므로 이제 데이터를 가져옵니다. 가져 오기 노드, 분류 용어, 주석 등. 나는 깨진 레코드처럼 들리지만 항상 각 단계를 완료 한 후에 테스트해야한다는 것을 알고 있습니다.

* 1 테마 테스트 : 이 프로세스는 매우 정교한 테마에서 까다로울 수 있습니다. 여기 몇 가지 포인터가 있습니다.

1. 외부 js 또는 css 라이브러리에 링크하는 경우 동일한 로컬 사본을 사용하십시오.

2. template.php 파일에서 전처리 함수 및 / 또는 후크 테마 함수뿐만 아니라 더 길거나 무한 루프를 가질 수있는 함수를 확인하십시오.

3. 다른 템플릿 파일 (page.tpl.php 등)을 확인하고 배열 및 객체의 원시 PHP 처리를 찾으십시오.

4. "보기"를 사용하고 템플리트 파일을 보는 경우에도 확인하십시오.

5. 항상 경로를 다시 확인하고 이미지, js 및 css 파일을 최적화하십시오. 단일 파일에서 여러 코드 스 니펫을 사용할 때 js 파일의 높이가 높은 경우가 있습니다.

* 2 테스트 모듈 : PHP에서 과도한 조작을 허용하므로 테스트 모듈은 약간 다릅니다. 다음은 몇 가지 사항입니다.

1. 커뮤니티 지원 모듈 (CCK, Views 등)은 drupal.org에 문제 대기열이있어 문제에 대한 기존 문제가 있는지 확인하고 문제를 해결하기위한 패치가있을 가능성이 있는지 확인하십시오.

2. 자신 만의 커스텀 코딩 된 모듈입니다. 코딩 한 경우 수정해야합니다. 코딩을 다시 확인하고 api.drupal.org에 대한 함수 사용법을 확인하십시오. 후크 대신 오버 킬링 함수를 사용 중일 수 있습니다.

3. 인터넷 공유 사용자 지정 코드 모듈은 2 단계에서와 같이 수행하지만 이번에는 원래 모듈 작성자에게 문의하여 문제에 대해 알려줄 수도 있습니다.

4. 사이트가 업그레이드 (D5-> D6-> D7) 인 경우 마이그레이션 또는 업그레이드 스크립트 (일반적으로 module.install 파일에서)를 확인하면 느린 SQL 쿼리 X를 더 빠르게 만들기 위해 새 테이블 구성에 추가 "인덱스"가 필요할 수 있습니다. .

5. 문제에 대한 터널 비전이 있다고 생각되면 조금만 나가서 완전히 관련이없는 다른 활동을 수행 한 다음 나중에 다시 방문하여 문제를 다시 방문하십시오.

6. 코드 섹션에서 문제를 지적했지만 문제 해결 방법에 대해 머리 나 꼬리를 만들 수없는 경우 프로그래밍 방법이나 Drupal의 작동 방식 및 방법에 대해 잘 모르는 사람에게 해당 섹션이 어떤 역할을하는지 설명해보십시오. 놀랄 준비가되었습니다.

참고 : 사이트를 재 구축 한 후에 컴퓨터가 가진 최고의 기능 중 하나 인 매력처럼 작동하기 시작하면 놀라지 마십시오.

제거하지 않고 모듈을 삭제하지 않았는지 다시 확인하십시오. Drupal이 파일을 찾으려고하지만 더 이상 존재하지 않기 때문에 지연이 발생합니다.

모듈이 더 이상 존재하지 않으면 변수 테이블에서 참조를 삭제하십시오.

newrelic 과 같은 Web APM 은 성능 문제를 추적하는 데 가장 적합한 도구입니다. 나는 한두 줄의 코드를 호출하여 이상한 일을하고 불필요한 배열을로드하고 APM으로 추적 할 때까지 보이지 않는 다른 일을하는 사이트를 가지고 있습니다.

누군가 GoDaddy가 느려질 것이라고 언급했습니다. 많은 클라우드 기반 호스팅 회사들도 AWS와 같은 서비스에 이러한 초기 지연이있을 것입니다. 서버의 우선 순위를 자동으로 낮추는 것이 더 저렴하며 이러한 서버는 '깨어나 기'위해 1-2 초가 필요합니다.

예를 들어, Pagodabox는 서버가 행복하게 깨어날 때까지 첫 바이트에 3-4 초가 있습니다. Pagodabox는 실제로 서버를 깨운 상태에서 수익을 창출하므로 사이트를 '보충'하기 위해 추가 비용을 지불 할 수 있습니다.

또한 CDN이 도움이 될 수 있습니다. 캐시 된 페이지 또는 이미지를 제공하여 웹 / DB 서버가로드되지 않습니다. 여기에 좋은 튜토리얼 : http://wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit

그리고 ... WebPageTest는 나를 행복하게합니다. http://www.webpagetest.org/ 전 세계 및 다른 웹 브라우저와의로드 시간을 무료로 비교하십시오. 이를 사용하여 변경 사항에 대한 실제 결과를 얻을 수 있습니다.

문제는 어디에나있을 수 있습니다.

1. 테마 나 모듈에서 디버그 모드를 설정하지 않았는지 확인하십시오. 예를 들어, 많은 테마에는 테마 레지스트리를 재생성하는 옵션이 있습니다.
2. Godaddy와 같은 공유 호스팅에서 실행중인 경우 처음 15 초 요청은 정상입니다.
3. Drush CTools Export 모듈을 사용하여 사이트 또는 프론트 페이지를 코드베이스로 변환하십시오 . 이것은 데이터베이스 호출을 제거하고 사이트는 PHP에서 완전히 실행됩니다.
4. 여전히 문제가 발생하면에서 query log및 page timer옵션을 켜서 Devel 설정을 사용하십시오 admin/config/development/devel. 두 페이지 중 어느 것이 전체 페이지를 생성하는 데 시간이 더 걸리는지 확인하십시오.
5. 아무것도 작동하지 않으면 서버를 다시 시작하십시오.
6. 최악의 경우 XHProf 를 설치 하여 문제가 발생한 곳을 확인하십시오.

이것이 설치 문제를 해결 한 방법입니다. 문제의 정확한 원인을 파악할 수 없으므로 실제 해결책은 아니지만 좋은 해결책입니다.

1) CSS 집계 (캐시 설정). 이것은 대기 시간을 절반으로 줄였습니다.

2) cron을 never로 설정하고 외부에서 실행하십시오. 참고 : "cron이 이미 실행 중일 때 cron을 시작하려고했습니다"오류가 발생했습니다. 나는 매번 시작할 때마다 cron을 시작하려고 시도했지만 실패했지만 cron 페이지는 최신 시도를 언급하지 않고 최신 성공을 언급했습니다.

3) Lynx를 통해 30 분마다 홈페이지를 호출하는 크론 작업 설정

이 모든 것은 공유 호스팅 서버에 있습니다. 최적은 아니지만 작동합니다.

Boost 모듈 (공유 호스팅에 있다고 가정) 또는 Varnish 라인을 따라 프론트 엔드 캐시를 사용하는 것이 좋습니다. 이것은 사이트 액세스가 주로 익명이고 페이지 내용이 동적이지 않은 경우 (즉, 페이지가 많이 변하지 않는 경우)에 가장 효과적입니다.

이러한 솔루션은 렌더링 된 페이지를 처음 액세스 할 때 저장 한 다음 전체 Drupal 부트 스트랩, 페이지 작성 및 테마 프로세스를 거치지 않고 사전 렌더링 된 html을 제공하여 특히 바쁜 사이트뿐만 아니라 귀하와 같은 사이트에서 많은 시간을 절약합니다. 어느 "잠을 자"고 일어나기까지 너무 오래 걸리는지 설명하십시오.

유일한 단점은 사이트 콘텐츠가 변경 될 때 캐시를 비워야한다는 것입니다. 사이트가 현재 컨텐츠로 완전히 캐시되도록하려면 drush cc all을 실행 한 다음 cron을 통해 주기적으로 전체 사이트에 대해 말리거나 wget 할 수 있습니다.