문제
개발 중인 Drupal 웹사이트의 성능 문제를 진단하려고 합니다. 아침에 사이트에 8시간 이상 트래픽이 없으면(크론 실행도 안 됨) 홈페이지를 로드하는 데 약 3.5초가 걸립니다. 페이지를 다시 로드하는 데 예상되는 시간은 250ms입니다.
이것은 꽤 오래된 버전의 PHP(5.3.3)가 설치된 개발용 웹 서버입니다.모든 파일은 NFS를 통해 정적으로 마운트됩니다.(저는 이것이 근본 원인이라고 생각합니다. 이에 대해서는 아래에서 자세히 설명합니다).
진단을 돕기 위해 설치했습니다.XHProf이 개발 서버에서 프로파일링 페이지를 로드하고 보기 좋게 정렬 가능한 테이블에 프로파일링 데이터를 표시하는 Drupal 모듈을 활성화했습니다. XHProf에 익숙하지 않은 사람들을 위해 호출된 모든 함수와 해당 함수에 대한 총 소요 시간, 메모리 사용량 및 호출과 같은 데이터를 제공합니다.
내 결과
초기 "느린" 적중에서 PHP 함수는 다음과 같은 file_exists작업을 수행했습니다.1400ms82개의 호출에서 전체 실행 시간의 약 43%를 차지합니다. 후속 페이지 로드 시 동일한 함수가 file_exists다시 82번 호출되었지만 이번에는 82번으로 극적으로 줄었습니다.3ms전체 실행 시간의 1%에 불과합니다.
나는 또한 PHP가 메모리에 로드하는 데 가장 오랜 시간이 걸린 파일을 살펴보았습니다( load::함수 이름에서 접두사가 의미하는 바가 바로 이것이었습니다). 이 PHP 템플릿 파일에는 엄청난 시간이 걸렸습니다.42ms처음으로 로드하려면3ms다음 재로드시!
내가 의심하는 것
어딘가에서 일종의 캐싱이 진행되고 있는 것이 분명합니다. 아직 어디인지는 모르겠습니다. PHP 문서파일이 존재이 함수의 출력이 캐시된다는 점을 언급하세요. 그러다가 내가 할 수 있다는 걸 알았어이 캐시의 크기를 제어그리고 아마도 기본 16k에서 Drupal(수많은 관련 파일을 로드하는)에 더 적합한 것으로 늘려야 할 것입니다.
그러나 이것이 에서 소요되는 시간을 줄일 것이라고 생각하지만 file_exists실제로 PHP가 소요되는 시간에 영향을 미칠지는 확실하지 않습니다.로드 중파일( load::앞서 언급한 것)을 삭제하고 이 값을 늘리면 파일 시스템의 근본적인 성능 문제가 숨겨지는 것 같습니다.
질문
- 증가하는 PHP가 XHProf에서
realpath_cache보고된 시간에 어떤 영향을 미쳤는지 확인할 수 있는 XHProf 또는 PHP 베테랑이 있다면 ?load:: - 영향을 미칠 수 있는 Linux에서 알아야 할 기본 캐싱 메커니즘은 무엇입니까?
- 위와 동일하지만 NFS용인가요?