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. Bu yüzden sorum iki misli olduğunu düşünüyorum:
PSS bu sitede kullanılan modül sayısı çok büyük (168) ama şu anda bu tavsiyeyi yapacak bir konumda değilim, daha çok delik durumundaki bir yangın gibi.
Edit: Yerel örnek (mikeytown tarafından önerilen) üzerinde xhprof çalışan çı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 ç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)
EDIT: Orijinal gönderi yanlış okudum. 168 modül çoktur ve 300 ila 700ms SQL sorgusu 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 şafağı yavaşlatır.
Ö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 () (bazen bir zamanlar renderleme API'sı) güzel bir API parçası (gerçekten kullanışlı) ama aynı zamanda biraz yavaş. 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ışan 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 dosyasını her yüklendiğinde FS üzerinde G/Ç yapmaya zorlayan çok küçük dosyadan yapılır bunlardan biri (APC de bunun için çok yardımcı oluyor).
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 barındırma kullanıyorsanız, Drupal spesifik (veya hazır) 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 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 olsa 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).