PHP 스크립트의 효율성을 벤치마킹하는 방법

PHP 스크립트를 벤치마킹하는 가장 좋은 방법이 무엇인지 알고 싶습니다. 크론 작업, 웹 페이지 또는 웹 서비스 여부는 중요하지 않습니다.

나는 마이크로 타임을 사용할 수 있지만 실제로 PHP 스크립트의 실시간을 제공합니까?

PHP에서 동일한 기능을 수행하는 다른 기능을 테스트하고 벤치마킹하고 싶습니다. 예를 들어 preg_matchvs strpos또는 domdocumentvs preg_match또는 preg_replace vs str_replace`

웹 페이지의 예 :

<?php
// login.php

$start_time = microtime(TRUE);

session_start(); 
// do all my logic etc...

$end_time = microtime(TRUE);

echo $end_time - $start_time;

이것은 다음과 같이 출력됩니다 : 0.0146126717 (항상 다양하지만 이것이 내가 얻은 마지막 것입니다). 이것은 PHP 스크립트를 실행하는데 0.015 정도가 걸렸음을 의미합니다.

더 좋은 방법이 있습니까?

실제 코드를 실제로 벤치마킹하려면 Xdebug 및 XHProf 와 같은 도구를 사용하십시오 .

Xdebug는 개발 / 스테이징 작업을 할 때 유용하며 XHProf는 프로덕션을위한 훌륭한 도구이며 지침을 읽는 한 안전하게 실행할 수 있습니다. 하나의 단일 페이지로드 결과는 서버가 백만 개의 다른 작업을 수행하고 리소스가 부족한 상태에서 코드의 성능을 확인하는 것과 관련이 없습니다. CPU에 병목 현상이 있습니까? 램? I / O?

또한 스크립트에서 실행중인 코드를 넘어서서 스크립트 / 페이지가 제공되는 방식을 살펴 봐야합니다. 어떤 웹 서버를 사용하고 있습니까? 예를 들어, nginx + PHP-FPM이 mod_php + Apache를 심각하게 수행하도록 만들 수 있습니다. mod_php + Apache는 좋은 CDN을 사용하여 정적 컨텐츠를 제공하는 데 어려움을 겪습니다.

다음으로 고려해야 할 것은 최적화하려는 것입니까?

• 사용자 브라우저에서 페이지를 렌더링하는 속도가 최우선 순위입니까?
• 최소 CPU 소비로 서버에 대한 각 요청을 최대한 빨리 철회합니까?

전자는 브라우저로 전송 된 모든 리소스를 gzipping하는 것과 같은 일을함으로써 도움이 될 수 있지만, 그렇게하면 (일부 상황에서) 후자를 달성하지 못하게 할 수 있습니다.

위의 모든 내용이 신중하게 격리 된 '실험실'테스트가 생산 과정에서 발생할 수있는 변수와 문제를 반영하지 않으며, 높은 수준의 목표가 무엇인지, 그리고 거기에 도달하기 위해 할 수있는 일을 식별해야한다는 것을 보여줄 수 있기를 바랍니다. 마이크로 / 조기 최적화 경로를 지옥으로 향하기 전에 .

완전한 스크립트가 서버에서 얼마나 빨리 실행되는지 벤치마킹하기 위해 사용할 수있는 도구가 많이 있습니다. 먼저 테스트를 검증하기 위해 스크립트 (예 : preg_match vs strpos)가 동일한 결과를 출력해야합니다.

당신이 사용할 수있는:

• jmeter
• ApacheBench 도구 ( 예제 참조 )
• 드 벤치
• http_load
• 컬 로더
• httperf
• 포위
• 식물
• 사용하는 코드도 좋지만 더 큰 루프 (예 : 1,000,000)

Xdebug ,보다 구체적으로 Xdebug의 프로파일 링 기능 을 살펴보고자 합니다 .

기본적으로 프로파일 러를 활성화하고 웹 페이지를로드 할 때마다 WinCacheGrind 또는 KCacheGrind 로 읽을 수있는 캐시 파일을 만듭니다. .

Xdebug는 구성하기가 약간 까다로울 수 있으므로 여기 php.ini에 참조 할 관련 섹션이 있습니다 .

[XDebug]
zend_extension = h:\xampp\php\ext\php_xdebug-2.1.1-5.3-vc6.dll
xdebug.remote_enable=true
xdebug.profiler_enable_trigger=1
xdebug.profiler_output_dir=h:\xampp\cachegrind
xdebug.profiler_output_name=callgrind.%t_%R.out

그리고 여기 WinCacheGrind.out 파일 의 스크린 샷이 있습니다 :

PHP 스크립트가 얼마나 효율적인지에 대한 자세한 정보를 제공해야합니다. 시간이 가장 많이 걸리는 대상을 타겟팅하려고합니다. 예를 들어 하나의 함수를 절반의 시간이 걸리도록 최적화 할 수 있지만 페이지로드 중에 수백 번이 아니라면 수십 번 호출되는 함수를 최적화하는 것이 더 좋습니다.

궁금한 점이 있다면 이것은 내가 사용하기 위해 작성한 CMS의 이전 버전 일뿐입니다.

https://github.com/fotuzlab/appgati를 시도 하십시오

코드에서 단계를 정의하고 두 단계 사이의 시간, 메모리 사용량, 서버로드 등을보고합니다.

다음과 같은 것 :

    $appgati->Step('1');

    // Do some code ...

    $appgati->Step('2');

    $report = $appgati->Report('1', '2');
    print_r($report);

샘플 출력 배열 :

Array
(
    [Clock time in seconds] => 1.9502429962158
    [Time taken in User Mode in seconds] => 0.632039
    [Time taken in System Mode in seconds] => 0.024001
    [Total time taken in Kernel in seconds] => 0.65604
    [Memory limit in MB] => 128
    [Memory usage in MB] => 18.237907409668
    [Peak memory usage in MB] => 19.579357147217
    [Average server load in last minute] => 0.47
    [Maximum resident shared size in KB] => 44900
    [Integral shared memory size] => 0
    [Integral unshared data size] => 0
    [Integral unshared stack size] => 
    [Number of page reclaims] => 12102
    [Number of page faults] => 6
    [Number of block input operations] => 192
    [Number of block output operations] => 
    [Number of messages sent] => 0
    [Number of messages received] => 0
    [Number of signals received] => 0
    [Number of voluntary context switches] => 606
    [Number of involuntary context switches] => 99
)

나는 xhprof를 조사 할 것이다 . 그것이 cli 또는 다른 sapi (fpm 또는 fcgi 또는 Apache 모듈과 같은)를 통해 실행되는지는 중요하지 않습니다.

xhprof의 가장 큰 장점은 프로덕션 환경에 적합하다는 것입니다. xdebug와 함께 작동하지 않는 것 (마지막으로 확인한 시간). xdebug는 성능에 영향을 미치며 xhprof (아무도 없다고 말하지는 않음)가 훨씬 잘 관리합니다.

xhprof를 자주 사용하여 실제 트래픽이 포함 된 샘플을 수집 한 다음 코드를 분석합니다.

그것은 당신에게 시간 과 모든 것을 얻는다는 점에서 실제로 벤치 마크가 아닙니다 . 프로덕션 트래픽을 매우 쉽게 분석 한 다음 수집 된 콜 그래프에서 PHP 기능 수준으로 드릴 다운 할 수 있습니다.

확장이 컴파일되고로드되면 다음을 사용하여 코드에서 프로파일 링을 시작합니다.

xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);

그만하다:

$xhprof_data = xhprof_disable();

그런 다음 데이터를 파일 또는 데이터베이스에 저장하십시오. 보트를 떠 다니거나 일반적인 런타임을 방해하지 않는 것이 무엇이든간에. 데이터를 중앙 집중화하기 위해 S3로 비동기식으로 푸시합니다 (모든 서버에서 모든 실행을 볼 수 있도록).

github 의 코드 에는 서버에 덤프하는 xhprof_html 폴더가 포함되어 있으며 최소한의 구성으로 수집 된 데이터를 시각화하고 드릴 다운을 시작할 수 있습니다.

HTH!

for더 현실적인 숫자를 얻기 위해 각 작업을 1,000,000 번 반복하도록 루프에 넣으십시오 . 실제로 벤치마킹하려는 코드 바로 전에 타이머를 시작한 다음 종료 시간을 기록하십시오 (즉, 타이머를 시작하지 마십시오).session_start() .

또한 타이밍을 정하는 기능을 제외하고 벤치 마크하려는 각 기능에 대해 코드가 동일한 지 확인하십시오.

스크립트 실행 방법 (cronjob, php from commandline, Apache 등)은 다른 함수의 속도 간의 상대적인 차이 만 타이밍하기 때문에 차이가 없습니다. 따라서이 비율은 동일하게 유지되어야합니다.

벤치 마크를 실행중인 컴퓨터에 다른 많은 작업이 진행중인 경우 벤치 마크가 실행되는 동안 다른 애플리케이션에서 CPU 또는 메모리 사용량이 급증하면 벤치 마크 결과에 영향을 줄 수 있습니다. 그러나 컴퓨터에 여분의 리소스가 충분하다면 이것이 문제가 될 것이라고 생각하지 않습니다.

좋은 시작은 xdebugs profiler http://xdebug.org/docs/profiler를 사용하는 것입니다

설정하고 사용하는 가장 쉬운 방법은 아니지만 일단 데이터를 가져 오면 볼 수있는 데이터의 양과보기가 대체 불가능합니다.

에릭,

당신은 자신에게 잘못된 질문을하고 있습니다. 스크립트가 ~ 15 mSec에서 실행되는 경우 시간은 크게 관련이 없습니다. 공유 서비스에서 실행하는 경우, PHP 이미지 활성화에는 ~ 100 mSec이 소요되며, 서버에서 완전히 캐시 된 경우 스크립트 파일 ~ 30-50 mSec을 읽고 백엔드 NAS 팜에서로드하는 경우 1 초 이상이 소요됩니다. 페이지 가구를로드 할 때 네트워크가 지연되면 몇 초가 걸릴 수 있습니다.

여기서 가장 큰 문제는 사용자가로드 시간을 인식한다는 것입니다. 링크를 클릭하고 완전히 렌더링 된 페이지를 얻는 것까지 얼마나 기다려야합니까? Ff 또는 크롬 확장 프로그램으로 사용할 수 있는 Google Page Speed 와 좋은 페이지 성능을 얻는 방법에 대해 자세히 설명하는 Pagespeed 설명서를 살펴보십시오. 이 지침을 따르고 페이지 점수를 90/100보다 향상 시키십시오. (Google 홈페이지는 내 블로그와 마찬가지로 99/100입니다.) 이것은 사용자가 인식하는 좋은 성능을 얻는 가장 좋은 방법입니다.

코딩 자체가 잠재적으로 앱의 성능을 방해하지 않도록 PHP 코드를 주시하고이 링크를 교차 점검하는 것이 좋습니다.