Bir D7 sitesini bir Minelli alt yapısı ile bir araya getirdim. Yol boyunca farklı temalar, farklı modüller ile birçok deneyler yaptım. Yol boyunca bir yerlerde tuhaf bir performans sorunu geliştirdim ve şimdi hangi temanın / modülün / konfigürasyonun neden olduğunu gerçekten bilmiyorum.

Sorun şu ki, siteyi ilk ziyaretimde ilk sayfanın gösterilmesi yaklaşık 15 saniye sürüyor. Daha sonra sitenin etrafında hareket edebilir ve çok duyarlı. Bir saat kadar bırakırsam, o zaman geri dön, ilk istek yine çok yavaş.

Önbelleği temizledim, bu yüzden sorun olmamalı. Ayrıca, kullanmadığım temaları ve modülleri devre dışı bıraktım. Siteyi yeni altyapıya taşıdım ama sorun onu takip etti!

Şimdi nereye gideceğim?

Kontrol edebileceğim üç şey var.

Bir, eğer bir üretim sitesinde çalışıyorsanız ve PHP dosyalarını düzenlemiyorsanız, APC'nin etkinleştirildiğinden, yeterli belleğe sahip olduğundan ve uzun bir TTL'ye sahip olmanız gerekir (bir güne gidebilir ya da asla sona ermeyebilirsiniz). Ayarı da düşünebilirsiniz apc.stat=0. APC dokümanlar Eğer TTL gerçekleştirmek için gereken tüm bilgilere sahip. Bellek miktarını seçmek için, apc.php dosyasını korumalı bir yere yapıştırmalı ve bellek kullanımını ve çalkalama istatistiklerini izlemelisiniz. APC hafızasını, kaçırılma oranınızın çok düşük olacağı şekilde ayarlayın. Başlangıçtaki yavaşlık APC'nin dolu ve boşalması olabilir (IIRC, APC, LRU veya daha gelişmiş önbellek stratejileri kullanmak yerine, tüm önbelleği doldurduğunda).

İkinci olarak, MySQL'in uygun şekilde ayarlandığından emin olun. Tampon boyutlarını ayarlamak için mysqltuner kullanabilirsiniz . Başlangıçtaki yavaşlığınız, disklerden tablo yüklemek ve / veya sorgu önbelleği eksikliğinden kaynaklanıyor olabilir. Mükemmel olmasa da, mysqltuner doğru yöne gitmenizi sağlıyor.

Üçüncü olarak, gerçek bir Drupal cron stratejisine sahip olduğunuzdan emin olun . Şahsen, "admin / config / system / cron" da otomatik cronu devre dışı bırakıp her gece çalıştırmak için bir crontab kurardım. Ayrıca , şeyler üzerinde daha hassas bir kontrol sahibi olmanız gerekiyorsa Elysia Cron'u da deneyebilirsiniz . Bu sayede, gerekli görevleri istediğiniz sıklıkta yapabilirsiniz, ancak normal olanları gece boyunca çalıştırın. İlk yavaşlığınız her saat başı cron koşularından kaynaklanıyor olabilir. Bunu, cron "admin / report / dblog" da çalıştığında ve yavaşlığınızla eşleştirmeye çalıştığınızda doğrulayabilirsiniz.

Ivanhoe123 muhtemelen haklıdır: Drupal 7, varsayılan olarak etkin olan 'fakir mans cron' ile birlikte gelir. Kısacası, (arada bir) cron'un Drupal'ın sayfayı oluşturmadan önce çalıştırılması, her şeyi geciktirmesi anlamına gelir.

Üretim sahalarında daima gerçek bir cron işi kullanmaya çalışın. Daha fazla teknik ayrıntı için http://drupal.org/cron adresini ziyaret edin veya barındırma şirketinizle konuşun.

Devre dışı bırakmak için admin / config / system / cron adresine gidin ve 'Asla'yı seçin.

Devel Eğer uzun süre çalışan sorguları olup olmadığını modül teklifler veritabanı günlüğü kontrol etmek.

Bu XHProf veya XDebug almanıza yardımcı olmaz ve suçlu kodu bulun. XHProf (bir profiler), sunucuda yürütülen tüm işlevlerin güzel bir haritasını çıkarır ve hangisinin en fazla yürütme zamanını harcadığını gösterir. Öte yandan, XDebug (bir hata ayıklayıcı) Eclipse (bir videoya bakın ) gibi bir IDE ile yapılandırıldığında, LIVE çalıştırılmakta olan her işlevi incelemenize olanak tanır. Profilci, neyin yürütüldüğü hakkında size bir fikir verecektir ; hata ayıklayıcı size neden idam edildiğini gösterecektir .

Sadece sorunun lezzetinden, hemen üç (3) şeyi düşünürüm.

• MySQL Depolama Motoru / İşlemci
• Veritabanı Önbelleğe Alma
• Masa kilitleme

MySQL Depolama Motoru

Herhangi bir FULLTEXT arama / endeksleme kullanmıyorsanız, tüm MyISAM verilerinizi InnoDB'ye dönüştürmenizi şiddetle tavsiye ederim. MyISAM, çoklu işlemcilerden ve çoklu çekirdeklerden faydalanmak için tasarlanmamıştır. InnoDB, çoklu CPU kullanımı ve okuma / yazma hiper-yayını için büyük ölçüde geliştirilmiştir.

İşte bu konuda DBA StackExchange'te ve bu sitede MySQL için InnoDB Performance'ı ayarlama konusunda yaptığım bazı yazılar

• Sep 20, 2011: Çok çekirdekli ve MySQL Performansı
• Sep 12, 2011: MySQL'in bir çekirdekten daha fazlasını kullanmasını sağlamak
• Jun 07, 2011: Bir veritabanını MyISAM'dan InnoDB'ye nasıl dönüştürebilirim?
• May 26, 2011: Tek iş parçacıklı ve çok iş parçacıklı veritabanı performansı hakkında
• Apr 15, 2011: https://drupal.stackexchange.com/questions/1715/what-would-be-the-optimal-mysql-configuration-for-a-drupal-7-site/2367#2367

Veritabanı Önbelleğe Alma

Tüm MyISAM verilerini InnoDB'ye dönüştürmenin bir başka güçlü argümanı, MySQL'in verileri / dizinleri önbelleğe almasıdır. MyISAM Depolama Motoru yalnızca dizinleri önbelleğe alır. InnoDB verileri ve dizinleri önbelleğe alır . Bunun ışığında, InnoDB Tampon Havuzuna aşağıdakilerden birini yerleştirmek için yeterli bellek ayırabilirsiniz (hangisi daha küçükse)

• Tüm InnoDB Veri ve Dizinler (OS için de yeterli RAM'iniz varsa idealdir; sonraki gecikmeleri ortadan kaldırır)
• Kurulu RAM'in% 75'i (RAM'in daha fazla InnoDB verisi / indeksine sahip olmanız durumunda; gecikmeleri en aza indirir)

MySQL 5.1 kullanıyorsanız, innodb_max_dirty_pages_pct = 0 olarak ayarlayabilirsiniz. Bu, disk G / Ç değerini biraz artıracaktır, ancak InnoDB Tampon Havuzu eski verilerin ve dizin sayfalarının disk G / Ç dalgalanmaları olmadan dönmesine izin verecek kadar temizlenir. MySQL 5.5 ve MySQL 5.1'in InnoDB Eklentisi, daha iyi bir varsayılan Tampon Havuzu yıkama mekanizmasına sahip olduğundan bu ayarlamaya ihtiyaç duymaz.

InnoDB kullanmak söz konusu değilse, memcached veya vernik ile gitmeniz gerekebilir. Bu, geliştiricinin, önbelleğe alınmış verilerin sunucu RAM'inde ne kadar kalacağını belirlemesini sağlar. Doğal olarak, bu, uygulamanızı ezberlenmiş / vernik uyumlu hale getirmek için gelişimsel geliştirme gerektirecektir.

Masa kilitleme

• InnoDB, işlemler ve engellemesiz okumalar için izin veren satır düzeyinde kilitleme yapar .
• MyISAM yalnızca her INSERT, UPDATE ve DELETE için tam tablo kilitlemesi yapar .

son söz

MySQL Yeniden Başlattıktan sonra ilk gecikmeden kaçınamazsınız. Yine de, yukarıda belirtilen önerileri / bilgileri kullanarak MySQL'i geliştirdikten sonra, sonraki gecikmelerle karşılaşmamanız gerekir.

Söz konusu sayfayı yüklediğinizde ve söz konusu sayfayı hemen yüklediğinizde tam olarak ne olduğunu belirlemek için YSlow veya Firebug vb. Gibi araçları kullanırdım. Önbelleğe alma sorunu olup olmadığını kontrol edin ve dahası, sayfaya adsız bir kullanıcı olarak ve ardından kimliği doğrulanmış bir kullanıcı olarak eriştiğinizde nasıl çalıştığını kontrol edin. Bunu Drupal içindeki performans ayarlarınızla karşılaştırın.

Önbelleğe alma sorunu değilse, veritabanında neler olup bittiğini görmek için Devel'in sorgu günlüğünün yanı sıra MySQL'in günlüklerini de kullanın. Ayrıca, sunucuda opcode veya benzer performans arttırıcı önbellekleriniz varsa, onlarla bazı numaralar almayı ve sonra tekrar açmayı deneyin.

Cron çalışıyor gibi geliyor.

Ayarlarınızı buradan kontrol edin: admin / config / system / cron

Neredeyse bu yüzden son projem için Drupal'ı düşürüyordum.

Yine de birden fazla sebep olmalı. Bu sorun sürünür her zaman işe yarayan bir 'hepsini düzelt' çözümü bulamadım.

Syslog ve Ubuntu / Debain

Aralıklı 15 saniye yükleme süresine rastladığım ilk seferde (Adanmış, paylaşılmayan) Debian / Ubuntu tabanlı sistemler üzerinde drupal çalışırken. Syslog modülünü devre dışı bırakmak benim için bir çözümdü.

@BetaRide'ın dediği gibi, xDebug veya başka bir PHP profiler kullanmak son derece aydınlatıcıdır.

Hala Bir Sorun - Bir Geçici Çözüm

Diğer yüklemelerime gelince, hala kayıptayım.

Bu sorun geliştirme sunucumda ve düşük trafikli Drupal yüklemelerimde daha belirgindir.

Geçici bir çözüm olarak, sitelerin ana sayfasını 60 saniyede bir yüklemek için bir cron işi ve her 300 saniyede bir Drupal'ın cron komut dosyasını hazırladım. Bu açıkça en uygun değil, ama bir insan ziyaretçi yerine 15 saniyelik yükleme süresinin sürmesini tercih ederim.

Birçok kişi bu sorunun , özellikle ağır cron işleriyle ilgili olan senkronize arka plan işlemlerini engellemeyle ilgili olabileceğini öne sürüyor .

Eğer doğruysa, gielfeldt * tarafından aktif olarak geliştirilmekte olan ve bu sorunu çözebilecek ya da en azından bazı ipuçları sunan ve site kurucularının davalarında belirli suçluları teşhis etmeleri ve tedavi etmelerine yardımcı olabilecek çok sayıda modül var . Her ikisi de engelleyici olmayan eşzamansız süreçleri engelleyici olmayan eşzamansız HTTP veya komutlarla değiştirir ve her ikisi de sorunlu işlemleri tanımlayabilen ilgili raporlar sunar:

• Arka plan süreci ve birlikte verilen modüller, Drupal'ın arka plan işlem sırasının zaman uyumsuz olarak işlenmesini sağlar, böylece engellemezler. Bu sorunu durdurabilir. Ayrıca, en son sürümde bulunan Arka Plan Süreci Apache Server modülü ile birlikte, başlangıç ​​zamanlarını ve bu işlemlerin ilerlemesini denetlemek, kilidini açmak ve incelemek için özelliklere sahip temel ancak iyileştirici bir UI raporu bulunmaktadır. Bu problem sürecini tanımlayabilir.
• Ultimate Cron , her biri bir UI'de izlenebilen ve durdurulan, cron ile tetiklenen görevlerin kendi ayrı asenkronize sce modüllerine sahip olmalarını sağlamak için Arka Plan Süreci üzerine kuruludur. Ağır hizmet performansında değişen görevleri düzenli düşük genel giderli temizlemeden ayırmak için mükemmel olmasının yanı sıra, her bir cronla tetiklenen görevin çalışma süresi, en son ne zaman çalıştıkları, şu anki durumu gibi uygun bilgileri içeren bir rapor da sunar. Bu, aynı zamanda sorunlu süreçlerden engellemeyi ve / veya tanımlamayı da kaldırabilir.

Her ikisi de zaten çok yararlı modüllerdir; bu problem için, blokajların senkron blokaj işlemlerinden veya cron akımlarından kaynaklandığı (çok makul sondaj) teorisini test etmek için kullanılabilirler. Potansiyel olarak, sorunu eşzamanlı değil de eşzamansız çalıştırarak çözebilirler ve ayrıca belirli işlemlerin beklemeye neden olduğu konusunda potansiyel olarak ipuçları sunabilirler. (dokümantasyonlarının devam eden bir çalışma olduğu konusunda uyarılmalıdır ...

Ancak, hiç yardımcı olacak şekilde yapılandırılamazlarsa, bu sorun için yalnızca senkronize arka plan işlemlerinden daha fazlası olduğunu gösterir. FWIW, bu modüllerin düzgün çalışmasını sağladığımdan (henüz dokunma dokunmamış ahşap) bu sitede hiç bu kadar özel bir sorun yaşamadım - ama daha önce sitelerimde ve vahşi yaşamdaki Drupal sitelerinde gördüm.

Ayrıca şu anda geliştirilmekte olan diğer eklenti modüllerinin de farkında olun - örneğin, karmaşık yüksek yoğunluklu durumlarda, eşik tabanlı azaltmaya izin veren Ultimate Cron Queue Scaler , cron ile ilgili performans sorunlarını azaltmaya yardımcı olabilir.

* Üyelik yok, sadece işlerini çok etkilendim

Bu bana bir kez daha çarptığından, sorunu araştırmaya başlıyorum. Bunu kesinlikle onaylayabilirim

1. drupal_cron_run()fakirlerin çekirdek cronu tarafından tetiklenen bir çağrı, dev makinemdeki istek süresine ~ 5s ekliyor. Bu yapılan çağrı etrafında testleri uncommenting test edilebilir drupal_cron_run()içinde modules/system/system.moduleyersystem_run_automated_cron()
2. tüm önbellekleri temizlemek, dev makinemde istek süresine ~ 2s ekliyor. Bu drush cc all, sayfanın tekrar yapılıp yeniden yüklenmesiyle test edilebilir .

Bu, cron'u hiçbir zaman ayarlamamayı ve cron'a crontab aracılığıyla bir çağrı eklemenin durumu daha iyi hale getirdiği anlamına gelir. Önbelleği yeniden doldurmak için sık kullanılan sayfaların hemen ardından basmak, kullanıcı deneyimini yeniden geliştirir.

Önbellekleme hakkında emin değilim. Bu sitenin varsayılan önbellek ayarlarına dokunmadım. Sanırım drupal zaman zaman tüm önbellekleri yeniden inşa ediyor olabilir, belki de cron tarafından tetiklenir, ama bunun nasıl yapıldığından emin değilim. Ancak bir 7s gecikme, birkaç saat sonra sayfaya çarptığımda gördüğüm şey.

Bu gibi konular sizi rahatsız edebilir ve benzer durumlarda bulunduğumda, sorunun bir anda ne adım attığını anlamaya yardımcı olur ve ardından adsız ve kayıtlı bir kullanıcı olarak test edin. (soğan katmanı yöntemi)

Birkaç temayla oynadıktan ve kendinize özel kodlama yaptıktan sonra sorunu fark etmeye başladığınızı belirtiyorsunuz. Sitenizin ne kadar karmaşık olduğunu ve arkasındaki mantığı bilmiyorum, ancak aşağıdaki adımlar sorunu bulmanıza yardımcı olacaktır:

1. Sunucunuzda, sitenizde kullandığınız sürümle temiz bir Drupal yüklemesi yapacağınız bir klasör veya başka bir hesap oluşturun (bu daha iyi olabilir). Ardından herhangi bir modül veya tema eklemeden, sitenin ilk isteği ve aşağıdaki isteği yanıtlaması için geçen süreyi test edin. Her şey yolunda giderse, sunucu yapılandırma sorunlarını göz ardı edebilirsiniz, geçerli durumunuzla aynı şekilde davranıyorsa, web sunucunuzla veya veritabanınızla bir yapılandırma hatası alırsınız.

2. 1. adımdaki sonuçlar iyi ve sunucu hızlı bir şekilde yanıt veriyorsa ve aşağıdaki istekler de hızlıysa, yalnızca mevcut sitenizdeki temayı temiz yükleme sitesine yükleyin ve yeniden test edin. Her şey hala hızlı yanıt veriyorsa, temanız sorun değil ve 3. adıma geçmelisiniz, aksi halde temanızda hata ayıklamaya başlamanız gerekir * 1.

3. Eğer 2. adımdaki testlerden sonra, site halen hızlı bir şekilde mevcut sitenizdeki modülleri devralmaya başlar ve her bir modülü ekleyip etkinleştirdikten sonra yanıt süresini test ettiğinizden emin olun * 2.

4. Tema ve modüller ekledikten sonra site yine de hızlı bir şekilde yanıt veriyorsa, yapılandırma eklemeye, içerik türlerini oluşturmaya, görünümleri içe aktarmaya, kurulum menülerine vb.

5. Kurulum ve konfigürasyon hazır ve site hala hızlı, peki şimdi verileri geri getirin. Düğümleri içe aktar, taksonomi terimleri, yorumlar vb. Kırık bir rekor gibi ses çıkarmam gerektiğini biliyorum, ancak her adımı tamamladıktan sonra her zaman test etmeliyim.

* 1 Test temaları: Bu süreç süper ayrıntılı bir temada zor olabilir, işte birkaç işaretçi:

1. Herhangi bir harici js veya css kütüphanesine bağlanırsanız, bunun yerel bir kopyasını kullanmayı deneyin.

2. Template.php dosyanızda, ön işlem işlevi ve / veya kanca teması işlevlerinin yanı sıra daha uzun veya sonsuz döngüye sahip olabilecek işlevleri kontrol edin.

3. Diğer şablon dosyasını (page.tpl.php, etc) kontrol edin ve dizilerin ve nesnelerin ham PHP işlemlerini arayın.

4. "Görünümler" kullanıyorsanız ve şablon dosyaları görüntülerseniz, o zaman da işaretleyin.

5. Yolları daima iki kez kontrol edin, görüntüleri, js ve css dosyalarını optimize edin. Bazen tek bir dosyada birden fazla kod parçacığını kullanırken js dosyalarının bazı ağırlıkları olabilir.

* 2 Test modülleri: Test modülleri biraz farklıdır çünkü PHP ile ağır manipülasyon kullanımına izin verilir. İşte bazı işaretçiler:

1. Topluluk destekli modüller (CCK, Views, vb.) Drupal.org'da sıraya girdiler ve probleminizle ilgili herhangi bir sorun olup olmadığını ve varsa bunları düzeltmek için bir yama olup olmadıklarını kontrol edin.

2. Kendi özel kodlanmış modülü, eğer kodlanmışsa düzeltmek zorundasın, değil mi? Kodlamanızı iki kez kontrol edin ve api.drupal.org adresindeki işlevlerin kullanımını kontrol edin, bir kanca yerine aşırı pişirme işlevini kullanıyor olabilirsiniz.

3. Internet paylaşımlı özel kod modülü, 2. adımda olduğu gibi yapın, ancak bu sefer orijinal modül yazıcısına da başvurabilir ve sorunu hakkında size bilgi verebilirsiniz.

4. Siteniz bir yükseltme ise (D5 -> D6 -> D7), geçiş veya yükseltme komut dosyalarını kontrol edin (genellikle module.install dosyasında), yavaş SQL sorgusu X'i daha hızlı hale getirmek için yeni tablo yapılandırmasında fazladan bir "index" gerekebilir .

5. Sorunla ilgili tünel vizyonunun olduğunu düşünüyorsanız, biraz dışarı çıkın ve tamamen ilgisiz başka bir aktivite yapın ve sonra konuyu tekrar ziyaret etmek için daha sonra tekrar gelin.

6. Sorunu bir kod bölümüne işaret ediyor, ancak düzeltilmesi konusunda kafa veya kuyruk yazamıyorsanız, bu bölümün nasıl programlanacağını veya Drupal'ın nasıl çalışacağını ve nasıl iş yapacağı hakkında hiçbir fikri olmayan bir kişiye ne yapması gerektiğini açıklamayı deneyin. sürpriz olmaya hazır.

Not: Sitenizi yeniden oluşturduktan sonra, bilgisayarların sahip olduğu en iyi özelliklerden biri olan bir cazibe gibi çalışmaya başlarsanız alarm olmayın.

Herhangi bir modülü kaldırmadan silmemiş olup olmadığınızı tekrar kontrol edin. Bu gecikmeye neden olur çünkü Drupal dosyaları bulmaya çalışır ancak artık orada değildir.

Modüller artık mevcut değilse değişkenler tablosundaki referansları silin.

Newrelic gibi bir Web APM , performans sorunlarını izlemek için en iyi araçtır. İşe yaramaz şeyler yapan, garip zamanlarda gereksiz diziler yükleyen ve bir APM ile takip edene kadar oldukça görünmez olan başka şeyler yapan bir veya iki kod satırı çağıran sitelerim oldu.

Birisi GoDaddy'nin yavaş olacağını belirtti. Pek çok bulut tabanlı barındırma şirketi de bu ilk gecikmeye sahip olacak çünkü AWS gibi hizmetler buna sahip. Sunucuların otomatik olarak sanallaştırılmaması daha ucuzdur ve bu sunucular 'uyanmak' için bir veya iki saniye daha ister.

Örneğin, Pagodabox ilk bayt için, sunucu mutlu bir şekilde uyanana kadar 3-4 saniyeye sahiptir. Pagodabox aslında sunucuyu uyanık tutarken para kazanmıştır ve bu yüzden sitenizi 'gizlemek' için ekstra ödeme yapabilirsiniz.

Ayrıca, bir CDN size yardımcı olabilir. Web / db sunucunuz önbelleğe alınmış sayfalar veya resimler sunacak şekilde yüklenmeyecektir. Burada iyi bir ders: http://wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit

Ve ... WebPageTest beni mutlu ediyor. http://www.webpagetest.org/ Gezegendeki ve farklı web tarayıcılarıyla yükleme sürelerini ücretsiz olarak karşılaştırın. Yaptığınız değişikliklerin gerçek dünya sonuçlarını elde etmek için bunu kullanın.

sorun herhangi bir yerde olabilir.

1. Herhangi bir tema veya modülde hata ayıklama modunu açmadığınızdan emin olun. Örneğin, pek çok temada tema kaydını yeniden oluşturma seçeneği vardır.
2. Godaddy gibi paylaşımlı bir hosting sunucusunda çalışıyorsanız, ilk defa talep ettiğinizde 15 sn normaldir.
3. Sitenizi veya ön sayfanızı Drush CTools Export modülünü kullanarak kod tabanına dönüştürün . Bu herhangi bir veritabanı çağrısını ortadan kaldıracak ve siteniz tamamen php'den çalışacaktır.
4. Hala sorun alırsanız, açarak Devel ayarlarını kullanmak query logve page timerde seçenekler admin/config/development/devel. İki sayfanın hangisinin sayfanın tamamını oluşturması için daha fazla zaman aldığını görün.
5. Hiçbir şey işe yaramazsa sunucunuzu yeniden başlatın.
6. En kötü durum , işlerin yanlış gittiğini görmek için XHProf'u yükleyin .

Demek kurulumum için sorunu bu şekilde düzelttim. Sorunun kaynağını çivileyemediğim için gerçek bir çözüm değil (eğer varsa), ama bu iyi bir çözümdür

1) Toplam CSS (önbellek ayarları). Bu gecikme süresini yarı yarıya düşürdü

2) cron'u asla (ve harici olarak çalıştır) 'a ayarlayın - Not: "Zaten çalışırken cronu başlatmayı denedim" hatalarımı yaptım. Sanırım her açılışta cronu başlatmaya çalışıyordu, ancak başarısız olduğu için cron sayfası en son denemeden değil, en son başarıdan bahsediyordu.

3) Her 30 dakikada bir Lynx ile ana sayfayı çağıran bir cron işi ayarlayın

Bütün bunlar paylaşılan bir barındırma sunucusunda. En uygun değil ama işe yarıyor

Boost modülünün satırları boyunca ön paylaşımlı önbellek kullanmanızı öneririm (paylaşımlı barındırmada olduğunuz varsayılarak) veya Vernik. Bu, sitenize erişilenlerin öncelikli olarak isimsiz olması ve sayfa içeriğinin, çoğunlukla dinamik olmayan (yani sayfaların fazla değişmemesi) olması durumunda en iyi şekilde işe yarar.

Bu çözümler, işlenen sayfaları ilk erişimde kurtarır ve daha sonra Drupal önyükleme, sayfa oluşturma ve tema işlemlerinden geçmek yerine önceden oluşturulmuş html'lere hizmet eder, özellikle yoğun siteler ve aynı zamanda sizin gibi siteler için çok fazla zaman tasarrufu sağlar hangisinin "uyumaya gittiğini" açıklayın ve uyanması çok uzun sürüyor.

Tek dezavantajı (en azından Yükseltme için) site içeriği değiştiğinde önbelleği temizlemeniz gerekmesidir. Sitenin mevcut içerikle tamamen önbelleğe alındığından emin olmak istiyorsanız, drush cc all'ı çalıştırabilir ve sonra cron aracılığıyla periyodik olarak tam siteye karşı kıvrılabilir veya wget yapabilirsiniz.