PHP betiğinin verimliliği nasıl karşılaştırılır

PHP betiklerimi karşılaştırmanın en iyi yolunun ne olduğunu bilmek istiyorum. Bir cron işi, web sayfası veya web hizmeti olması fark etmez.

Mikro zamanı kullanabileceğimi biliyorum ama bu gerçekten bana bir PHP betiğinin gerçek zamanını veriyor mu?

PHP'de aynı şeyi yapan farklı fonksiyonları test etmek ve kıyaslamak istiyorum. Örneğin, preg_matchvs strposveya domdocumentvspreg_match veya preg_replace ile str_replace`

Bir web sayfası örneği:

<?php
// login.php

$start_time = microtime(TRUE);

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

$end_time = microtime(TRUE);

echo $end_time - $start_time;

Bunun çıktısı: 0.0146126717 (her zaman değişir - ama bu elime geçen sonuncusu). Bu, PHP betiğini çalıştırmak için 0,015 kadar sürdüğü anlamına gelir.

Daha iyi bir yol var mı?

Gerçekten gerçek dünya kodunu karşılaştırmak istiyorsanız, Xdebug ve XHProf gibi araçları kullanın .

Xdebug, geliştirme / aşamalandırma konusunda çalışırken mükemmeldir ve XHProf, üretim için harika bir araçtır ve orada çalıştırmak güvenlidir (talimatları okuduğunuz sürece). Tek bir sayfa yüklemesinin sonuçları, sunucu milyonlarca başka şey yapmaya zorlanırken ve kaynaklar kıtlaşırken kodunuzun nasıl performans gösterdiğini görmek kadar alakalı olmayacak. Bu başka bir soruyu gündeme getiriyor: CPU'da darboğaz mı yaşıyorsunuz? VERİ DEPOSU? G / Ç?

Ayrıca, komut dosyalarınızda çalıştırdığınız kodun ötesine, komut dosyalarınızın / sayfalarınızın nasıl sunulduğuna da bakmanız gerekir. Hangi web sunucusunu kullanıyorsunuz? Örnek olarak, nginx + PHP-FPM'yi ciddi bir şekilde mod_php + Apache gerçekleştirebilirim, bu da iyi bir CDN kullanarak statik içerik sunmaktan vazgeçer.

Dikkate almanız gereken bir sonraki şey, ne için optimize etmeye çalıştığınızdır?

• Sayfanın kullanıcıların tarayıcısında sunulma hızı bir numaralı öncelik midir?
• Hedef, en az CPU tüketimiyle sunucuya her isteği olabildiğince çabuk geri atmak mı?

Birincisi, tarayıcıya gönderilen tüm kaynakları gzip ile göndermek gibi şeyler yaparak yardımcı olabilir, ancak bunu yapmak (bazı durumlarda) sizi ikincisini elde etmekten uzaklaştırabilir.

Umarım yukarıdakilerin tümü, dikkatlice izole edilmiş 'laboratuar' testinin üretimde karşılaşacağınız değişkenleri ve sorunları yansıtmayacağını ve yüksek seviye hedefinizin ne olduğunu ve oraya ulaşmak için neler yapabileceğinizi belirlemeniz gerektiğini göstermeye yardımcı olabilir. cehenneme giden mikro / erken optimizasyon yoluna gitmeden önce .

Komple betiğinizin sunucuda ne kadar hızlı çalıştığını ölçmek için kullanabileceğiniz birçok araç vardır. Testinizi nitelemek için önce komut dosyanızın (örneğin preg_match vs strpos) aynı sonuçları vermesi gerektiğinden emin olun.

Kullanabilirsiniz:

• Jmeter
• ApacheBench aracı ( bir örneğe bakın )
• dbench
• http_load
• kıvırmak yükleyici
• httperf
• kuşatma
• vegeta
• kullandığınız kod da iyidir, ancak daha büyük bir döngüye sahiptir (1.000.000 gibi)

Xdebug'a ve daha spesifik olarak Xdebug'un profil oluşturma yeteneklerine bakmak isteyeceksiniz .

Temel olarak, profilcisini etkinleştirmek ve her zaman onunla okunabilen bir cachegrind dosya oluşturur bir web sayfasını yüklemek WinCacheGrind veya KCacheGrind .

Xdebug'ı yapılandırmak biraz zor olabilir, bu nedenle php.inireferans için benim ilgili bölümüm:

[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

Ve WinCacheGrind'deki bir .outdosyanın ekran görüntüsü :

Bu, PHP betiğinizin ne kadar verimli olduğu hakkında bol miktarda ayrıntı sağlamalıdır. En çok zaman alan şeyleri hedeflemek istiyorsunuz. Örneğin, bir işlevi yarı zaman alacak şekilde optimize edebilirsiniz, ancak çabalarınız, sayfa yükleme sırasında yüzlerce olmasa da düzinelerce adı verilen bir işlevi optimize ederek daha iyi sonuçlanacaktır.

Merak ediyorsanız, bu sadece kendi kullanımım için yazdığım bir CMS'nin eski bir sürümü.

Https://github.com/fotuzlab/appgati'yi deneyin

Kodda adımların tanımlanmasına ve iki adım arasında zaman, bellek kullanımı, sunucu yükü vb. Raporlar sağlar.

Gibi bir şey:

    $appgati->Step('1');

    // Do some code ...

    $appgati->Step('2');

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

Örnek çıktı dizisi:

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
)

İçine bakmak istiyorum xhprof . Cli üzerinde veya başka bir sapi (fpm veya fcgi veya hatta Apache modülü gibi) üzerinden çalıştırılması önemli değildir.

Xhprof'un en iyi yanı, üretimde çalıştırılacak kadar uygun olmasıdır. Xdebug ile iyi çalışmayan bir şey (en son kontrol ettiğimde). xdebug performans üzerinde bir etkiye sahiptir ve xhprof (hiçbiri olmadığını söyleyemem) çok daha iyi yönetir.

Gerçek trafiğe sahip örnekleri toplamak için sık sık xhprof kullanıyoruz ve ardından kodu oradan analiz ediyoruz.

Bunu da yapsa da, size zaman kazandırması açısından gerçekten bir ölçüt değil . Sadece üretim trafiğini analiz etmeyi ve ardından toplanan çağrı grafiğindeki php işlev düzeyine inmeyi çok kolaylaştırır.

Uzantı derlendikten ve yüklendikten sonra, kodda şu şekilde profil oluşturmaya başlarsınız:

xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);

Durdurmak için:

$xhprof_data = xhprof_disable();

Ardından verileri bir dosyaya veya veritabanına kaydedin - teknenizde ne olursa olsun yüzer ve normal çalışma süresini kesintiye uğratmaz. Verileri merkezileştirmek için bunu eşzamansız olarak S3'e aktarıyoruz (tüm sunucularımızdan tüm çalıştırmaları görebilmek için).

Github kod sunucuda ve minimal yapılandırma ile dökümü bir xhprof_html klasörü içeren, sen toplanan verileri görselleştirmek ve aşağı sondaj başlayabilir.

HTH!

forDaha gerçekçi bir sayı elde etmek için her şeyi 1.000.000 kez yapmak için bir döngüye koyun . Ve zamanlayıcıyı yalnızca karşılaştırmak istediğiniz koddan hemen önce başlatın, ardından bitiş zamanını hemen kaydedin (yani, zamanlayıcıyısession_start() .

Ayrıca, zamanlama yaptığınız işlev haricinde, karşılaştırmak istediğiniz her işlev için kodun aynı olduğundan emin olun.

Komut dosyasının nasıl çalıştırıldığı (cronjob, komut satırından php, Apache, vb.), Yalnızca farklı işlevlerin hızı arasındaki göreceli farkı zamanladığınız için bir fark yaratmamalıdır. Yani bu oran aynı kalmalıdır.

Karşılaştırmayı çalıştırdığınız bilgisayarda başka pek çok şey varsa, kıyaslamanız çalışırken başka bir uygulamadan CPU veya bellek kullanımında bir artış olursa bu, kıyaslama sonuçlarını etkileyebilir. Ancak bilgisayarda ayıracak çok kaynağınız olduğu sürece bunun bir sorun olacağını düşünmüyorum.

İyi bir başlangıç, xdebugs profiler http://xdebug.org/docs/profiler kullanmaktır

Belki kurması ve kullanması en kolay şey değil, ancak bir kez kullanmaya başladığınızda, büyük miktarda veri ve görüntüleme kolaylığı yeri doldurulamaz.

Eric

Kendine yanlış soruyu soruyorsun. Betiğiniz ~ 15 mSec içinde çalışıyorsa, zamanı büyük ölçüde önemsizdir. Paylaşılan bir hizmet üzerinde çalıştırırsanız, PHP görüntü etkinleştirme işlemi ~ 100 mSn, ​​sunucuda tam olarak önbelleğe alınmışsa komut dosyalarının okunması ~ 30-50 mSn, ​​arka uç NAS çiftliğinden yüklüyse muhtemelen 1 veya daha fazla saniye sürecektir. Sayfa mobilyalarının yüklenmesindeki ağ gecikmeleri çok fazla saniye ekleyebilir.

Buradaki ana sorun, kullanıcıların yükleme süresi algısıdır: Bağlantıya tıklamakla tamamen işlenmiş bir sayfa almak arasında ne kadar beklemesi gerekir. Ff veya chrome uzantısı olarak kullanabileceğiniz Google Page Speed'e ve iyi sayfa performansının nasıl elde edileceğini derinlemesine tartışan Pagespeed belgelerine bir göz atın . Bu yönergeleri izleyin ve sayfa puanlarınızı 90 / 100'den daha iyi almaya çalışın. (Google ana sayfasının puanı blogumun yaptığı gibi 99/100). Bu, kullanıcı tarafından algılanan iyi bir performans elde etmenin en iyi yoludur.

Kodlamanızın potansiyel olarak uygulamanın performansını bozmadığından emin olmak için gözlerinizi PHP kodunuzda tutmak ve bu bağlantıyla çapraz kontrol yapmak da iyidir .