답변:
SVN 푸시 환경에서 실행되므로 스크립트를 사용하여 apc 파일 캐시 만 지 웁니다.
APC 설정 :
apc.ttl=604800
apc.user_ttl=3600
apc.shm_size=192M
apc.include_once_override=1
auto_globals_jit=Off
apc.num_files_hint = 2048
apc.stat_ctime = 0
apc.file_update_protection = 2
apc.stat = 0
PHP 스크립트 :
<?php
$return = apc_clear_cache('opcode');
echo var_export($return);
604800 = 1 주
그런 다음, xdebug / xhprof를 시작하고 사이트를 캐시 갈기 작업을 수행하면 사이트 속도 저하 원인을 알려야합니다. 간단히 말해 캐시 그라인드 출력을 분석하는 것이 Drupal 속도를 높이는 가장 좋은 방법입니다. 아래에는 속도를 높이기 위해 사용하는 패치 및 모듈이 나와 있습니다. 귀하의 경우에는 가장 다를 것입니다.
Drupal 6 특정 답변 아래
이 시점을 지나서 APC가 원하는 것을 제공하지 않을 것이라는 것을 깨닫고 나면 pressflow로 전환 하고이 패치에 소용돌이 를 주십시오 .
또한 사이트 속도를 크게 개선 한 다음 모듈 중 일부를 사용해보십시오.
이것은 "문자열 질문의 길이는 얼마입니까"중 하나입니다.
대용량 사이트에 유용한 것은 많은 모듈이있는 저용량 사이트에 대해 동일하지 않을 수 있으며, 소수의 모듈 만 활성화 된 중간 규모 사이트에 대해서는 동일하지 않을 수 있습니다. 서버에서 실행중인 다른 사이트도 APC가 사용할 수있는 메모리를 사용하고있을 수 있습니다.
나의 출발점은
apc.enabled=1
apc.shm_segments=1
apc.shm_size=64
apc.ttl=7200
apc.user_ttl=7200
apc.num_files_hint=1024
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.enable_cli=1
apc.rfc1867=1그런 다음 서버의 설정을 조정하지만 모든 설정에 맞는 크기는 없습니다.
apc.php (아마도 /usr/share/pear/apc.php에 있음)를 찾아 Drupal 설치를 위해 DOCROOT에 설치하십시오. Apache 설정을 통해 IP 주소로 고정하십시오. 내부에서 사용자 이름 / 암호를 편집 한 다음 찾아보십시오. 그러면 APC 통계가 표시됩니다.
캐시 누락을 최소화하려면 shm_size 매개 변수를 재구성하십시오. 이상적으로는 파일에 대한 캐시 누락과 APC 사용자 캐시에 대한 추가 메모리를 갖지 않을만큼 충분한 메모리를 제공하고자합니다.
캐시 변동을 방지하기 위해 TTL을 최적화하십시오. 파일을 편집하지 않는 경우이 수를 늘릴 수 있습니다.
enable_cli는 drush를 많이 사용할 때 편리하므로 drush는 APC에서 캐시 된 파일을 사용합니다.
rfc1867은 파일 업로드에 편리합니다.
나는 또한 제목에서 php-fpm을 발견했습니다. 이것은 문제를 복잡하게 만들고 실제로 Drupal Answers의 범위를 벗어납니다. 많은 시스템 구성 설정이 Drupal과 직접 관련이 없으므로 Server Fault 에서 더 나은 응답을 얻을 수 있습니다 .
APC는 PHP 파일의 로딩 및 파싱을 개선합니다. 대부분 실행 시간 자체이기도합니다. 버그 (특히 캐시 관련 버그), 내부 오버 헤드 (예 : drupal_alter (), module_implements ()) 등 실행 시간을 늘릴 수있는 많은 요소가 있습니다.
mikeytown2가 요청하고 이미 제안한 것처럼 xhprof를 사용하여 병목 현상이있는 곳을 찾기 위해 xhprof를 사용합니다 (요즘 xdebug보다 선호합니다. 결과에 직접 빠르고 빠르게 액세스하고 추가 도구가 필요하지 않습니다).
최근 Drupal에서 xhprof 를 사용하는 방법 과 일반적인 병목 현상 에 대한 두 개의 블로그 게시물을 작성했습니다 .