WordPress ne kadar iyi ölçeklenir?

Yeni WordPress ve yeni özellikleri ile WordPress basit bir blog motorundan çok daha fazlasını yapabiliyor gibi görünüyor. Peki , WordPress ölçeğinin günde 10k -> 100k kullanıcıları tarafından kullanılması ne kadar iyi?

Bu kadar çok kullanıcı ile büyük bir kısmı iyi bir önbellek stratejisine sahip olmak olacaktır, ancak WordPress bu konuda kolaylık sağlamak ve ihtiyacınız olan kontrolü size vermek için ne kadar iyi geliştirilmiştir. Fx, bir sayfanın bir kısmını önbelleğe almak ve yalnızca kullanıcıya özel parçalar oluşturmak, ana / bağımlı db kurulumunu ve bunun gibi şeyleri desteklemek?

Açıkça hiçbir şey hızlı bir web sunucusu tarafından sunulan statik dosyaların ve neyin yüklenip yüklenmeyeceğini bulmak zorunda olan herhangi bir CMS'nin ölçeklenmesi ve aynı zamanda WordPress veya başka bir şekilde gerçekleştirilmemesi anlamına gelmez. Sorunlardan biri, her URL isteği için gereken veritabanı sorgusu sayısıdır ve önceki 2 yıllık Drupal ile çalışıyorum ve şimdi 2 + yıl olan WordPress ile çalışmak WordPress'in bu bölümde çok daha iyi olması.

Bununla birlikte, herhangi bir gücü olan neredeyse hiçbir şey “kullanıma hazır” olarak ölçeklenemez ; Hepsi , ölçeklenebilirlik ihtiyaçlarınız arttıkça ne yapabilirsiniz?

"Çok fazla trafik" in düşük ucunda , harika önbellekleme eklentileri ve ucuz CDN'ler ile entegrasyonlar vardır, BT dışı bütçeyle ve düşük barındırma bütçesinde oldukça iyi bir iş yapabilirsiniz. İşte incelenecek diğer sorular ve cevaplar:

• Sunucu Yüküyle İlgili WordPress'i Optimize Etme Adımları?
• Destek Eklentileri Dahil WordPressli CDN Seçenekleri?
• WordPress'i Amazon CloudFront Önbelleğe Alma için Yapılandırma

Performans darboğazlarını tanımlamak için profil oluşturma seçenekleri vardır :

• Paylaşılan Barındırmada Bir WordPress Web Sitesi Dağıtmak için Profil Oluşturma?

Darboğazlar tespit edildikten sonra , Transients API gibi şeylerle yerelleştirilmiş optimizasyon yapabilirsiniz . Bu soru-cevap, Transients API kullanılarak optimize edilebilecek bir örnek verir ve aşağıdakileri gösterir:

• Kategori Başına Sınırlı Gönderi ile Birden Çok Kategoriyi Sorgulamak için WP_Query Kullanımı?

Eğer bir şey gerçekten büyük silahları çıkarmak istiyorsan , işleri hızlandırmak için Memcached , HyperDB , Nginx ve / veya daha fazlasını yapılandırabilirsin.

• WordPress'iniz için Memcached'i Etkinleştirin
• Nginx ve WP Super Cache ile WordPress Nasıl Hızlandırılır
• hyperdb
• WordPress için ön uç proxy önbelleği olarak Nginx

Ve son olarak WP Engine , ZippyKid ve diğerleri gibi performans konusunda uzmanlaşmış WordPress odaklı web siteleri ortaya çıkıyor :

• Üstün WordPress web barındırma teknolojisinin en iyi özellikleri mi?

Bu yüzden iyi haber tüm ölçekler çok güzel ; teknik karmaşıklığı olan düşük ve son derece kolay olan teknik kolaylık ve maliyet sadece trafik önemli ölçüde büyüdükçe büyür. WordPress ile küçük başlayın ve harika olacak. Trafiğiniz büyüyorsa ve makul derecede iyi para kazanıyorsanız, ihtiyaç duyduğunuz ölçüde ölçeklendirmek için çok uygun maliyetli bir etki bulacaksınız.

En azından IMO. :)

1. Çok fazla paylaşılan barındırma beklemeyin - paylaşılan bir ana bilgisayar iseniz WordPress yavaşlık için suçlamayın. Paylaşılan ana bilgisayarlar 1000'den fazla hesabı tek bir sunucuya tıkayabilir. Böylece bütün gününü 10 $ / ay'lık bir hesabı optimize ederek geçirebilirsiniz. Ayrıca buzzwords pazarlamaya da dikkat edin - sadece "bulut" ifadesinin bir sunucuyu 100 veya 1000 kişiyle paylaşmadığınız anlamına gelmediği anlamına gelir.

2. Bu noktada önbellek eklentilerinin gerekli olduğunu sanmıyorum. WP kaynak koduna bakarsanız, çekirdeğe eklenmiş önceden önbellekleme zaten var. Önbelleğin önbelleğinin bir önbelleği - dikkat edin, bu ters etki olabilir.

3. Sizi yavaşlatan en önemli şey yavaş MySQL sorguları ve WordPress'in kullanıma hazır olması sizi rahatsız etmemelidir. Ancak, yorum sorgularımı "SINIR Etmek" zorunda kaldım, çünkü 50.000'den fazla yorumum vardı. (Bu henüz düzeltildi mi?) Ayrıca, atipik bir şey yapıyorsanız (1000 kategori gibi?) Bu da bir sorun olabilir.

4. NginX ile bir Linode 512 kullanıyorum ve "top" PHP ve NginX'in işlerini istek başına saniyenin 1 / 100'ünden daha azında yaptığını gösteriyor. Neredeyse tüm CPU zamanı MySQL ile bağlanmıştır. 20 dolarlık bir Linode ile ayda 1 milyon sayfa sunabilirsiniz, ancak bir kez eklenti ve fotoğraf eklemeye başladığınızda, "1GB" bir Linode'ye ihtiyacınız olacağını düşünüyorum. Benim bakış açıma göre, bu oldukça doğrusaldır: Sayfa görünümleri iki katına çıkarsa, Linode'nizin boyutunu iki katına çıkarın.

Feragatname: Linode için çalışmıyorum.

Güncelleme (~ 2 yıl sonra) bir sayfanın bölümlerini PHP ile önbelleğe almak istediğinizden, şaşırtıcı derecede hızlı kullandığım basit bir çözüm. Saniyenin 1 / 100'ünde sayfa başına birkaç ayrı parça / kısım önbelleğe alıyorum. Bir ramdisk bu işi daha da hızlandırabilir gibi görünüyor ama benim ihtiyaçlarım için oldukça hızlı:

$cache_file = "./cache/portion-1". $since; // maybe round() this $since timestamp
$cache_life = 1000; // seconds to keep this cached
$filemtime = filemtime($cache_file);  // returns FALSE if file does not exist
if (!$filemtime or (time() - $filemtime >= $cache_life)) {

    // heavy lifting starts
    $output = 'Heavy!';
    // heavy lifting ends

    if (!file_put_contents($cache_file,$output,LOCK_EX)) { echo 'error'; } // save the cache    
    echo $output;

} else { 

    // load from cache
    $output = file_get_contents($cache_file); 
    echo $output;        
} 

Sonunda WordPress'i yavaşlatan 3 şey var ve bunlar bunu kaynaştırıyor:

• Hosting yığını - en son yazılımla iyi bir sunucuya ihtiyacınız var - PHP 7, Nginx, Varnish, Redis, fail2ban ve PerconaDB hepsi iyi seçenek.
• Tablo taraması yok - birçok eklenti tablo taramasının ne olduğunu bile bilmeyen amatör kodlayıcılar tarafından yazılır. Tablo taramalarını önlemek için iki şeye ihtiyaç vardır: kullanılabilir bir dizin ve dizini kullanabilecek şekilde yazılmış bir sorgu
• PHP döngülerinde SQL sorgusu yok ya da çok az - bazı eklenti kodları yalnızca küçük siteler üzerinde açıkça test edildi ve bir nedenden ötürü veritabanınızdaki her üründen geçerek her ürün / gönderi için yeni bir SQL çağrısı yapacak. İdeal olarak sayfa başına 100'den az SQL sorgusu istiyorsunuz - çok kulağa hoş geliyor, ancak bu gerçekten değil ve <100 ile 200ms civarında önbelleksiz bir TTFB elde edeceksiniz.

Yukarıdakileri uyguladıktan sonra önbellekleme ekleyebilirsiniz - örn. Cila, CDN'ler, sayfa önbelleğe alma vb.

Ölçeklemeniz gerekirse, veritabanı için PerconaDB XtraDB ve dosyalar için Unison kullanarak bir küme oluşturabilirsiniz. Bu şekilde, wp-admin ve cron runner'ınız olarak 1 düğümü ve bir yük dengeleyicisinin arkasında web trafiği sağlayan diğer düğümler olabilir.