Drupal sayfa yürütme süresine ne katkıda bulunur?


17

Ben büyük performans sorunları olan araştırıyorum bir sitem var, memcache kullanarak hem sayı hem de toplam uygulama süresi (3 saniye ila 230 ms) hem de sorgu sayısını azaltmak başardı ama sayfa yürütme süresi beni kaçınıyor devel tarafından verilen değerlere baktığımda) benim anlayışım sayfa yürütme süresi = php yürütmek için geçen zaman bu yüzden APC yükledim ve APC kontrol panelinde apc.php (APC ile sevk apc.php) önbelleğe alınan ve istatistik isabet gösteren görebilirsiniz ama sayfamın yürütme süresi azalmıyor. Bence sorum iki misli:

  • Sayfa yürütme süresine ne katkıda bulunur (daha iyi yavaşlar)? Php yürütmek için sadece zaman aldı mı?
  • Sayfa yürütme süresini azaltmak için hangi yaklaşımları kullanmalıyım? APC'yi denedim ama fazla yardım etmedim

Bu sitede kullanılan modüllerin PS sayısı sadece çok büyük (168) ama şu anda bu tavsiyeyi yapacak bir konumda değilim, daha çok delik durumundaki bir yangın gibi.

Düzenleme: Yerel örnek (mikeytown tarafından önerilen) üzerinde çalışan xhprof çıktı, bu deli gibi görünüyor sonraki sonuçlar thrashing nedeniyle olduğunu düşünüyorum? aynı url için diff çalışır büyük bir fark ve sadece çok fazla kaynak kullanımı var. Ayrıca bugün neden olmayan değerleri gösteriyor emin değilim: | (Bu dizüstü bilgisayara xhprof'u yeni yükledim)

Yerel örnekte xhprof çalıştırmanın çıktısı

Yanıtlar:


4

Sitenizin önbelleğini alın. xdebug veya xhprof bir tane üretebilir. Bu, hangi işlevlerin en uzun süre çalıştığını size söyleyecektir. Bunu yapana kadar, bu kötü bir tahmin oyunu.


Hey, öneri için teşekkürler sadece yerel geliştirme sürümümde xhprof çalıştırdım (dizüstü bilgisayar sunucuda değil) ve bunu görüyorum - picasaweb.google.com/lh/photo/… Bu gerçek mi? Yani bir sayfanın 750Mb bellek tüketmesi bile mümkün mü?
Mart'ta Dipen

Çöplük yüzünden olabilir mi? aynı url için daha sonra profilli veriler, eğer u altta bakarsanız aynı url çok daha az kaynak alır, ancak bir diff çalıştırma tamamen diff ve aşırı kaynak kullanımını gösterir.
Mart'ta Dipen

1
Gerçekten bağlıdır, ancak 100MB'ın üzerinde koç kullanmanız yanlışsa kurulumların% 99,9'u için.
mikeytown2

Modül sayısı dışında yanlış bir şey olabilir mi? Modüllerin hemen üretimden kaldırılıp kaldırılamayacağından emin değilim. Btw, yerel üzerinde nginx + php-fpm kullanıyorum ve üretimde site hızlı cgi ile lighspeed kullanıyor.
Mart'ta Dipen

1
Önbellekleme işlemini incelemeniz ve tüm zamanlarınızda hangi işlevin yendiğini listelemeniz gerekir. img715.imageshack.us/i/cgrindout.png
mikeytown2

1

EDIT: Orijinal yazıyı yanlış okudum. 168 modül çok ve 300 ila 700ms SQL sorguları çok büyük . Ne kadar çok modül kullanırsanız, modüller bunu yapar yapmaz o kadar çok sorgu olacaktır.

Yaparken agresif önbellekleme kullanın, her şeyi önbelleğe alın, yeterli değilse, ters proxy önbelleğini deneyin. Dosyalar için bir CDN kullanmak her şeyi büyük ölçüde geliştirebilir. Ters proxy önbellek, gerekli olmayan sayfaları vururken bazı kimlik doğrulama çerezlerini kaldırarak da size yardımcı olabilir (daha sonra çekirdek, kullanıcının bunlar için anonim olduğunu ve önbelleği en üst düzeye çıkaracağını düşünür).


Drupal çekirdek dinamizmi, aynı anda çok fazla sayıda modülün etkileşime girmesiyle tüm şafak yavaşlar.

Örneğin, alanları kullanmak yerine hook_node_load () zamanında veri yükleyen çok sayıda modül kullanırsanız, alan kullanımı önbellek verimliliğini sağlarken çok fazla sorgu yapar diyorum.

Oluşturma da çok zaman alabilir, drupal_render () (ara sıra oluşturma API'si) güzel bir API parçasıdır (gerçekten kullanışlı) ama aynı zamanda biraz yavaştır. PDO'ya (D7) ve tam DBTNG'ye (bu arada harika) geçiş de ihmal edilemez bir gecikme ekler.

Bununla birlikte, çekirdek kendi başına oldukça hızlıdır (ancak neredeyse hiçbir şey yüklenmemiş olsa bile çok fazla SQL sorgusu yapar), kötü kodlanmış modüller genellikle darboğazdır.

APC, çalıştırılan koda bağlı olarak yürütme süresini 2 veya 3'e bölebilir. iyi yapılandırırsanız (tüm APC optimizasyonlarını etkinleştirin, resmi APC kılavuzu iyi yazılmıştır ve size yol gösterecektir).

Yavaş dosya sistemine (ağ dosya sistemi veya yavaş sabit sürücü) sahip bir kutu üzerindeyseniz, yürütme süresi üzerinde gözle görülür bir etkisi olabilir. Drupal, PHP'yi FS'yi her birini yüklediğinde I / O yapmaya zorlayan birçok küçük dosyadan yapılır (APC de bunun için çok yardımcı olur).

Yanlış yapılandırılmış bir DBMS de oldukça çirkin bir darboğaz olabilir, eğer MySQL kullanıyorsanız ince ayar yapmayı düşünün. Paylaşılan bir hosting kullanıyorsanız, Drupal'a özgü değilse (veya hazırsa) DBMS ve PHP yığını muhtemelen yanlış yapılandırılmış veya ayarlanmamıştır, bu da gerçekten yavaş sitelere yol açabilir.

Tüm önbellekleri etkinleştirmeyi unutmayın. Sitenizin kimliği kullanıcı odaklı değilse, agresif sayfa önbelleğini etkinleştirin (gerçekten şaşırtıcı).

Görünürlüğünüzü kısıtlamazsanız, bloklarınız ne kadar fazla olursa sayfalar o kadar yavaş olur, Views modül blokları şafak bir darboğaz olur (kullandığınız Views eklentilerine bağlı olarak OG bloğu gerçek bir acı olabilir). sayfa başına veya özel PHP koduyla (başka herhangi bir blok da her zaman blok görünürlüğünüzü manuel olarak ayarlayın, boş bloklar oluşturmaya çalışmaktan kaçınarak çerçeveye büyük ölçüde yardımcı olur).

Her sayfada yavaşlayan bir 403 veya 404 alsanız bile, hook_init (), hook_init () kullanan modüllerden kaçının (imagecache | style nesil süresini yavaşlatır ve dosyalardaki 404 hataları bile sadece dosyanın var olmadığını söylemek için yavaşlayın).


Merhaba, burada sayfa yürütme zamanı dediğimde, sayfanın altındaki devel modülü tarafından gösterilen ve SQL sorguları vb. De içeren genel drupal istek / yanıt döngüsü anlamında kullanmayan değeri kastediyorum. kimliği doğrulanmış kullanıcı bağlamında. Peki devel rapor sayfa yürütme zamanı da sql sorguları içerir?
Mart'ta Dipen

15k RPM linux dosya sisteminde olduğum gibi dosya sisteminin bir darboğaz olup olmayacağından emin değilim. SQL sorguları sayfaya bağlı olarak yaklaşık 300-700 ms sürer ancak sayfa yürütme süresi ~ = 3 sn (devel tarafından rapor edilir). Sorunun başka ne olabileceğinden emin değilim.
2018'de Dipen

Üzgünüm, orijinal yayınınızı yanlış okudum. Devel değeri, önyüklemeden kapanmaya kadar hesaplanır (devel modülünde, bunun dahil olmak üzere birçok şey yapmak için kendi PHP kapatma işleyicisi vardır). Ne zaman başladığını ve durduğunu tam olarak bilmiyorum, ancak hemen hemen tüm Drupal sayfa oluşturma süresi ve iş özellikleri o sayfa yürütme süresine dahil edildi. Evet, her şeyi (SQL sorgu süresi ve gecikmesi dahil) ve kendi gecikmesini (devel sorgu günlüğü de bir performans etkisine sahiptir) içerir.
Pierre
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.