Bellek performansını iyileştirmek için Wordpress'e yeniden düzenleme [kapalı]


63

Wordpress bellek tüketimine yakından baktım. Sitemde, 20MB RAM'in tahsis edildiği her sayfa için, sadece tüm eklentilerin çalışabileceği rahat bir ortam hazırlamak için tahsis edilmiş gibi görünüyor.

İyileştirilecek tek bir nokta yok, hafızanın çoğunu yiyen tek bir kötü adam yok. Tüketim, pek çok php modülüne yayılmıştır.

Wordpress'in ortamını sadece bir kez belleğe başlatmasını ve ardından her bir isabet için tekrar kullanmasını nasıl sağlayabiliriz? Yavaş PHP'nin her kullanıcı tıklamasında 20 MB yemesini istemiyorum - çok fazla bellek içeren bir sunucuda bile, tüm bu işleri halletmek birkaç saniye sürüyor. Temel olarak, yeniden kullanılabilecek salt okunur bellek parçalarına ihtiyacınız olacak.

Ayrıca ... neden 20 MB? Bu konuda herhangi bir görüş bildiren var mı?

Düzenleme: Geliştirme makinemde çalışan Wordpress'in WinCacheGrind çıktısı (paylaşılan barındırmadan çok daha hızlı). Gördüğünüz gibi, sadece ana sayfanın HTML kodunu oluşturmak için bir saniyeden fazla süren bir işlem sürüyor. Bunu paylaşılan barındırma tarafından yavaşlatın ve sorun için bir tarifiniz olsun. Çoğu zaman alan yöntemi seçtim. Bunu optimize etmeye nasıl devam edersiniz?

Düzenleme: İşte bu fantastik functions.php profilleme aracından sorgu istatistikleri .

Yük: 12 sorgu - 532ms - 19.1MB - 43 önbellek isabet / 53
Sorgu: 15 sorgu - 563ms - 19.0MB - 72 önbellek isabet / 86
Ekran: 21 sorgu - 705ms - 19.2MB - 234 önbellek sayısı / 257

Düzenleme: Seni korkutmak için garantili bir şey görmek ister misin? Bu satırları index.php'nin sonuna ekleyin:


echo "<pre>\n";
print_r(get_defined_vars());
echo "</pre>\n";

Şu anki gönderinin gövdesinde bellekte depolanan kaç kez olduğunu saymaya çalıştım. 20 örnek saydım. Sonra PHP'nin referans sayımı olduğunu fark ettim, bu yüzden kopya sayısı sadece üçe düştü: ikisi WP_Query'de, biri nesne önbelleğinde. Daha fazla araştırıyorum.

Bu nedenle WordPress'in bellek sorunlarını hedeflemede yeniden düzenlemeye ihtiyacı olduğunu düşünüyorum. Artık hafıza tüketimini, yaptıklarının karmaşıklığı için suçlayamazsınız. Sadece bir sürü yanlış yapar .

Düzenleme: Bunu anlamaya çalışırken bir gün sonra, benim bulgularım:

1) Tüm hafızanın% 88'i, bir çağrı türü gerektirir veya include veya include_once'dan gelir:

2) php dosyası çoğunlukla, bir isteğin sunulmasının ilk bölümünde (şaşırtıcı olmayan bir şekilde), tüm hafızanın yendiğini içerir:

3) İstek sırasında yürütülen tüm fonksiyonları göstermek ilginçtir. Toplam 12000'den fazla arama var. Onları daha görünür kılmak için titrettim (Seviye ekseni temelde yığının derinliğidir):

4) Aklıma gelebilecek tek yol, içerilen .php dosya miktarını en aza indirmektir. Geldikleri dosya başına işlevleri bölersem, birçok dosyanın en fazla bir veya iki kez isabet ettiğini görebilirsiniz. Gerekmediğinde bunları atlamanın bir yoluna ihtiyacımız var. Örneğin, uzak veritabanı yedekleme eklentim, hiç kullanılmayacak şekilde yüklenir ve kaydedilir. İşte dosya adıyla bölünen yukarıdaki arsa:

Bloglarımın hafızasını% 30 veya daha fazla kesmemize neden olacak yeniden yapılanmalar için :) itibarımıza değer bir ödül sunuyorum.

Düzenleme: WP 3.1'i yükledim, eski sürümle karşılaştırmak burada.

Mavi WP 3.1, kırmızı 3.0.4'tür. Yeni WP daha hızlı, ancak daha fazla hafıza da yiyor.

İşte dosyaya göre bir liste.

Bu, "All In One SEO pack" tarafından ne kadar hafıza tüketildiğini fark etmeme izin verdi - bir cadde istediklerimi elde etmek için eklentinin işlevselliğinin sadece bir kısmını kullanmak olacaktır. Ayrıca, kendi eklentilerim oldukça kötü görünüyor.

Koşullu yüklemeyi, örneğin comment.php (blogumdaki yorumlara izin vermiyorum) ve diğerleri üzerine yüklemeyi denemek istiyorum. Kaldırılan tüm kodları sildim. Kses.php dosyasını yalnızca talep üzerine global tablolarını yüklemek için kestim. L10n'yi basitleştirdim (yerelleştirme yapmam), işlevlerini dizeleri hemen arama yapmadan döndürür hale getirdim. Hala keyfi bir şekilde kurduğum% 30 işaretinden uzaktayım.

Düzenleme: APC'yi varsayılan ayarlarla (32 MB opcode önbellek) indirdim ve etkinleştirdim. İşte karşılaştırma:

Kod yüklemesinin büyük oranda hızlandığını ve kodun hafızada daha az yer kapladığını görebilirsiniz (muhtemelen sadece orijinal kaynak koduyla değil sadece opcodlarla uğraştığımız için). Hafıza tüketimi ise yine de oldukça yüksektir.


Cachegrind dosyasını kendi kendine bir yere yükleyebilir misin? Sadece not edin, özel tutmaya değer bir şeyin dahil olup olmadığını, hatırlamıyorum - öyleyse.
Rarst


1
hm, senin sonucuna katılıyorum - hiçbir şey gerçekten atlamaz, düzeltilmek ister. Yerel test yığımda (3.1, MS, Yirmi On, Tema Ünite Testi verisi) yeni bir profil çizdim ve 1,5'im var (farkın çoğu özel menüden kaynaklanıyor gibi gözüküyor). Yani düzeltmek için hiçbir şey tahmin etmeyin = araştırmayı önbelleğe almak.
Rarst

@Rarst Yardımlarınız için çok teşekkür ederim. Düzeltilmesi gereken şeyler olduğunu düşünüyorum, ancak Wordpress'in mimarisini tamamen farklı bir felsefeye dönüştürmek gerekiyor ve bu çok fazla iş.
Roman Zenka

Yanıtlar:


25

Belaya değmez. Çünkü WordPress çok fazla hafıza yemez. Çok fazla bellek tüketir, çünkü kaputun altında çok fazla işlev görür.

Statik önbellek eklentisiyle sonuçları (sayfa oluşturulur) önbelleğe almak ve sunmak çok daha kolay ve verimlidir. Bu şekilde çoğu ziyaretçi WP'nin kendisine bile vurmayacak.


2
Zaten bir önbellek kullanıyorum, ancak doğada gerçekten dinamik olan birkaç sayfam var (ör. Alışveriş sepeti). Yıldızlar doğru şekilde hizalanmadığında, kullanıcı 20 saniye bekleyebilir - yani GoDaddy'de verilir, ancak olmasa bile en azından ~ 3 saniye olacağını düşünüyorum. İnsanların Google’dan alıştığı, gerçekten çabuk bir deneyim yaşayamıyorum.
Roman Zenka

8
@Roman Zenka, belirli performans gereksinimleriniz varsa, WordPress'in kendisinin sihirli bir şekilde süper hızlı ve kaynaklara ışık tutacağını ummak yerine, belirli çözümler aramanız daha iyi olacaktır. Bakmamı önerdiğim ilk şeyler opcode önbellek ve statik önbellekleme parçası ... Ama ondan önce dikkatini ölçmek ve sadece hafızanın nereye gittiğini değil, aynı zamanda zamanın nerede harcandığını da belirlemek zorundasın. WordPress, çevredir, tek başına bir darboğaz değil. Darboğaz, yaptığın şeyde.
Rarst

@Rarst Aslında CPU kullanımını kıyasladım ve sorun yaratan herhangi bir yere parmakla işaret edemiyorum. Belleğe benzer - her yere yayılmış gibi görünüyor. Bununla birlikte, kıyaslama işlemim optimum şekilde yapılamayabilir - XDebug profiler ve Cachegrind kullanıyorum - örneğin veritabanı aramaları nedeniyle gecikmeyi ortadan kaldırmak oldukça zor. İşaretçilere daha iyi profil oluşturma teknikleri için minnettar olurum.
Roman Zenka

@Rarst Profiling ekran görüntüsü eklendi.
Roman Zenka

4
GoDaddy'nin sunucularının yavaş olması da olabilir. En iyi donanıma sahip olmadıkları bilinir ve " sunucularını yükseltmek yerine televizyon reklamları için ödeme yaparlar "
Zack

23

Bu yüzden WordPress'in tekrar yazmaya ciddi ihtiyacı olduğunu düşünüyorum. Artık hafıza tüketimini, yaptıklarının karmaşıklığı yüzünden suçlayamazsınız. Sadece işleri yanlış yapar.

Ne kadar saf bir sonuç. Oku You Do asla söylenmeyecek şeyler, Bölüm I .

Yine de hafıza kullanımı için teşekkürler.

Çok daha sonra düzenleyin: Autommatic, istediğinizi yaptığınız gibi görünen prefork adında bir kütüphane yayımladı : WordPress kodunu RAM'e yalnızca bir kez yükleme.


Doğru, saf. Belki de "yeniden yazmak" yerine "refactor" demeliydim, o zaman çok daha iyi geliyor. Yayın güncellendi.
Roman Zenka

2
: Belirli önerileri (özellikle yamalar) varsa iyi, Tamam, sen pistte bir bunları yayınlayabilirsiniz core.trac.wordpress.org
scribu

Şu an üzerinde çalışıyorum. Hafızadaki nesnelerin haritasını çizmeye çalışıyorum, böylece ne tarafından ne kadar kullanıldığını görebiliyorum. Bir bellek dökümü ve arsa alacak bir araç var mı?
Roman Zenka

5
@scribu - Joel'in gönderisine bağlantı için +1!
MikeSchinkel

1
Tamam, sadece WP_Object_Cache bir memcached uygulama vb ile değiştirilebilir unutmayın
scribu

17

WordPress 3.2'den başlayarak, PHP 5.2 minimum gereksinim olacaktır. Bununla birlikte, kemerlerimizin altında, çekirdeğin bitlerinin yeniden yapılandırılmaya başlayabileceğini ve otomatik yüklemeli sınıfları kullanabileceğini düşünüyorum. Bu, aslında gerekli olmadıkça bazı kod parçalarını yüklememize izin verir . Örneğin, sayfa görünümünde gömme veya galeri olmasaydı, çok fazla medya kodu yüklemekten kaçınabiliriz.

Ancak, o rotaya gitmeye karar verseler bile, yavaş bir evrim olmasını beklerdim (gerçekleşen diğer kaput altı değişikliklerin çoğu gibi). Bazı eklentiler için muhtemelen geriye dönük olarak uyum sağlayabilen çok sayıda dosya ve kodun bulunduğu yerde karıştırılması gerekir.

Sorunun bir kısmı (eğer buna gerçekten adlandırılabilirse), bu tür şartlı yükleme olmadan, çekirdek çerçevenin, içerik görünümünü oluşturmak için hangi işlevselliğe ihtiyaç duyacağını veya ihtiyaç duymayacağını önceden bilemeyeceğidir. Dolayısıyla , ihtiyaç duyulması halinde birçok fonksiyonun yüklenmesi gerekir.


@Dougal Campbell En azından% 30 bellek tüketiminde iyileşme sağlayacak kadar kötü bir şekilde WordPress'in bu örneğini hackleyebilip kesemeyeceğimizi görmek için bu soruya bir ödül aldım. Gelecekteki gelişmelerden bazılarına ilham verebilir.
Roman Zenka

Koşullu yükleme, bellek tüketimini potansiyel olarak azaltırken, opcode önbelleklemesi söz konusu olduğunda hızı düşürür . Hızı tercih etme eğilimindeyiz.
scribu

Otomatik yükleme hakkında daha fazla düşünce: stackoverflow.com/questions/4788452/…
scribu

@scribu "Koşullu yükleme" derken, otomatik yüklemeden mi bahsediyorsunuz, yoksa bir koşula göre kod yüklemek mi istiyorsunuz? Hızı ne kadar acıtıyor?
Roman Zenka

1
Teşekkür ederim! Dediğim gibi, WP çekirdeğinin o yolu izleyip izleyemeyeceğini bilmiyorum (gereken yeniden yapılandırma çok fazla olabilir). Ama bunu analiz etme çabanızdan ve yarattığınız grafiklerden çok etkilendim. İyi çalışmaya devam et!
Dougal Campbell

16

Wordpress'in ortamını sadece bir kez belleğe başlatmasını ve ardından her bir isabet için tekrar kullanmasını nasıl sağlayabiliriz?

Buna opcode önbellekleme denir.

http://en.wikipedia.org/wiki/PHP_accelerator


1
APC'ye bir deneyeceğim ve ne olacağını göreceğim. İlk başta bu soruyu sorduğumda, sadece opcode önbelleğe almaktan daha fazlasını kastetmiştim - WordPress'in oluşturduğu tüm ortamı yeniden kullanmak istedim - code + data. Memcached veriyi daha hızlı elde etmenize yardımcı olacaktır, ancak yine de verileri sunucu belleğinde klonlayacaksınız. Şimdi, opcode önbelleklemenin potansiyel olarak tüm bellek tüketiminin ~% 90'ını karşılayacağı düşünülmektedir.
Roman Zenka

Bazı deneyler için kaynaklarınız varsa, bir FastCGI ortamı kurmayı da deneyebilirsiniz. Mod_php ve FastCGI altında çalışan bazı karşılaştırmalar çok ilgimi çekecektir.
Dougal Campbell

5

Muhtemelen RAM kullanımını azaltmayı başaramazsın. Ancak kullanıyorsanız mod_php, mod_fcgidbunun yerine geçmek isteyebilirsiniz .

mod_php biraz daha yavaş olsa da, görüntüleri sunma, statik dosyalar ve hatta önbellekleme gibi gerekmediğinde php yükler. Çok fazla isteğin varsa, bu çok fazla koç.

fcgid kullanmak bunu çok azaltacaktır.

Ayrıca, statik önbellek kullanmak (w3total önbellek gibi) php'yi çağırmaktan kaçınacaktır , ki bu gerçekten büyük bir avantajdır: daha az ram kullanımı, daha az db bağlantısı.


4

Ha. Ben tamamen benim paylaşılan barındırma hesabı işleyebilir ötesinde veri ve kullanımı ile aşırı niyetinde artık bir web uygulaması üzerinde çalışıyorum, bu yüzden karar - çalışan denemek için - WP inşa etmek süper kolay olurdu iken BackPress olarak bir çerçeve ve sadece benim özel kullanım durumları için ihtiyacım olanı inşa et.

Böylece çekirdek ortamımı WP'deki yüzlerce PHP dosyasından sadece yirmi ya da gerçekte ihtiyaç duyduğum kadar azaltabildim, ancak hala tüm db, HTTP, kullanıcı yönetimi, biçimlendirme ve cron'undan yararlanabiliyordum. WordPress'te sevdiğim işlevler.

Sorun şu ki, bu çok fazla iş ve benim kişisel kullanımım dışında bir şey için hackjob'uma asla güvenmeyeceğim. Tüm WP ortamını kullanmak istiyorsanız, olduğu gibi kullanın. Yüzlerce geliştiricinin birkaç yıl içinde ince ayar yapması nedeniyle olduğu kadar iyi. Buradaki herkesin dediği gibi, daha iyi bir barındırma planı bularak ve önbellekleme tekniklerini araştırarak çekirdeği hacklemekten daha fazlasını elde edersiniz.


1
WP'nin uzun süredir ince ayar yapıldığını kabul ediyorum. Ancak, eklentileri belirli bir karışımı ile, berbat barındırma üzerinde çalışmak için ince ayar olduğunu sanmıyorum. Ne kadar zorlayabileceğimi merak ediyorum. Değişiklikler çekirdekte kalmasa bile, yapmanız gerektiğini düşünüyorsanız, çekirdeği hacklemenin belgelenmiş bir yolunun olması iyidir.
Roman Zenka

3

Evet, WordPress ilk önce her şeyi yükler ve sonra ne yapmamızı istediğimizi yapar. RAM içine dosya koyabileceğimiz sanal bir havuz oluşturabileceğimiz bir yeri hatırlayabilirim. Tüm WordPress'i belleğe koyma fikrim vardı (<10MB) ve sonra tek başına hız artışı sağlayacak çok fazla G / Ç tasarrufu yapabiliriz. Ama asla deneme şansım olmadı ve dahası, böyle bir şeyi takip etmede gerçekten o kadar da yetkin değilim. Ama denemeye değer görünüyor.


Ve hiçbir işlem yapılmadığı için statik önbellek eklentisi kullanmak için Rarst ile aynı fikirdeyim. Ancak bu, iyi dinamiklerle de kullanılabilir. :)
Ashfame

Bu fikri sevdim. Bu sorunun ne kadarının G / Ç gecikmeleri nedeniyle olduğundan ve PHP'nin veriyi yavaşça çiğnemesinden ne kadar kaynaklandığından emin değilim. Nasıl söyleyeceğinizi biliyor musunuz?
Roman Zenka

Üzgünüm bu sadece kafamda bir fikir. Verilerin genellikle sabit diskten bloklar halinde okunması gibi göründüğü gibi performansı etkilemeyebilir, bu nedenle gerekli olan birçok veri zaten alınmış olabilir. Ben pek emin değilim.
Ashfame

3

birkaç temel öneri:

  1. Önbellekleme için w3 toplam önbellek eklentisi ..
  2. memcache'i kurun ve etkinleştirin, ayrıca w3 toplam önbellek ayarlarından da etkinleştirin (opcode önbellek de iyi bir seçenektir, ancak w3 toplam önbellek eklentisi ile iyi gitmez)
  3. tema dosyalarındaki bağlantıları yönlendirmek için sorguları en aza indirin ..
  4. Kullanılmayan tüm eklentileri devre dışı bırakın ve çıkarın.
  5. Veritabanını optimize et.

Ben her gün büyük trafik ile iyi bilinen bir wordpress sitesi çalıştırıyorum .. im adanmış bile değil, benim için harika yapıyor :)

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.