Modern WordPress Sunucu Yığınına Bir Bakış

Yalnızca bir Apache sunucusu ve PHP ile "hızlı" bir WordPress web sitesini ne zaman çalıştırabileceğinizi hatırlıyor musunuz? Evet, o günlerdi! O zamanlar işler çok daha az karmaşıktı.

Şimdi, her şey yıldırım hızında yüklenmeli! Ziyaretçiler, yükleme süreleri konusunda eskisi gibi aynı beklentilere sahip değiller. Yavaş bir web sitesi sizin veya müşteriniz için ciddi sonuçlar doğurabilir.

SmashingMag'de Daha Fazla Okuma :

• Uygun WordPress Dosya Sistemi İzinleri ve Sahiplikleri
• Bir WordPress Web Sitesini Sorunsuz Taşıma
• MAMP ile Yerel Olarak WordPress Nasıl Geliştirilir
• WordPress ile Kendin Yap Önbelleğe Alma Yöntemleri

Sonuç olarak, WordPress sunucu yığını, bu hız ihtiyacına ayak uydurmak için yıllar içinde gelişmek zorunda kaldı . Bu evrimin bir parçası olarak, motoruna birkaç vites eklenmesi gerekti. Eski viteslerden bazıları da değişmek zorunda kaldı.

Sonuç olarak, WordPress sunucu yığını bugün birkaç yıl öncesine göre oldukça farklı görünüyor. Bunu daha iyi anlamak için bu yeni yığını ayrıntılı olarak inceleyeceğiz. Bir WordPress web sitesini hızlı hale getirmek için çeşitli parçaların nasıl bir araya geldiğini göreceksiniz.

genel bakış

Dalmadan önce, biraz uzaklaşalım ve büyük resme bakalım. Bu yeni WordPress sunucu yığını neye benziyor? İşte cevap:

Yukarıdaki şema, modern WordPress sunucu yığınının nasıl göründüğüne dair iyi bir genel bakış sunar. Yüksek düzeyde, olup bitenleri üç alana ayırabiliriz:

• tarayıcı ve WordPress arasındaki istek-yanıt döngüsü;
• WordPress (PHP çalışma zamanının yürüttüğü bir komut dosyasıdır);
• WordPress ve MySQL veritabanı arasındaki sorgu-sonuç döngüsü.

Modern WordPress sunucu yığınının rolü, bu üç alanı optimize etmektir. Bu optimizasyonlar, her şeyin daha hızlı yüklenmesini sağlayan şeydir. Ve en iyi yanı, bunu yapmanın birkaç yolu olmasıdır. (Yaşasın!)

Çoğu durumda, bu optimizasyonlar sunucunuza yeni hizmetler yüklemeyi içerir. Bazen bu hizmetler, WordPress ile etkileşim kurmak için bir eklentinin yardımına ihtiyaç duyabilir. Sadece bir eklenti kurarak kurtulabileceğiniz zamanlar da olacaktır. Bu makale boyunca birçok farklı seçenek göreceksiniz.

İstek-Yanıt Döngüsü

Her şey tarayıcı ile başlar. Diyelim ki modern.wordpress-stack.org ana sayfasını görüntülemek istiyorsunuz. Tarayıcınız, onu barındıran web sunucusuna bir HTTP isteği göndererek başlayacaktır. Diğer uçta, web sunucusu isteğinizi alacak ve onu bir HTTP yanıtına dönüştürecektir.

Bu ilk yanıt her zaman modern.wordpress-stack.org ana sayfasının HTML içeriği olmalıdır (bir hata yoksa). Ancak, tarayıcınızın işi bitmedi. Hayır, bu ana sayfanın hala daha fazla dosyaya ihtiyacı var, en yaygın olanları CSS, JavaScript ve resim dosyalarıdır.

Böylece, tarayıcı bu dosyalar için istek gönderecektir. Web sunucusu, istenen dosyalarla yanıt verecektir (yine, herhangi bir hata olmadığı sürece). Bu döngü, tarayıcı ana sayfayı oluşturmak için yeterli bilgiye sahip olana kadar devam edecektir. Bu döngü ne kadar hızlı gerçekleşirse, web sitesi o kadar hızlı yüklenir.

Şimdi, bu bariz bir basitleştirme, ancak WordPress web sitelerinin çoğu için işler böyle yürüyor.

İstek-Yanıt Döngüsünü Optimize Etme

Pekala, bu bizi bariz soruya getiriyor: Bir web sunucusunun bu döngüyü daha hızlı gerçekleştirmesini nasıl sağlarız? Bu harika bir soru ve modern WordPress sunucu yığınının var olmasının nedeninin bir parçası.

Yığın var çünkü bir web sunucusunu daha hızlı yapamazsınız. Bir web sunucusu aynı zamanda bir göndericidir. Bir istek alabilir ve sadece diğer hizmetlere iletebilir.

Bu diğer hizmetler genellikle bu istek-yanıt döngüsünün darboğazıdır. WordPress ile bu darboğaz PHP'dir, bu nedenle istek-yanıt döngüsünü optimize etmek iki şeye indirgenir. Web sunucusunun şunları yapmasını istiyoruz:

• mümkün olduğunca az istek almak,
• PHP'ye mümkün olduğunca az istek iletin.

Modern WordPress sunucu yığını bu sonuncuya odaklanır. PHP'ye mümkün olduğunca az istek iletmek istiyor. Yığını optimize etmenin ana hedefi bu olacaktır.

İkinci hedefe odaklanıyoruz çünkü yığın ilki hakkında pek bir şey yapamıyor; üzerinde doğrudan bir etkisi yoktur. İkincisi, ya web sunucusunun konfigürasyonu ya da modern geliştirme teknikleri ile ele alınmaktadır.

İstek-Yanıt Döngüsü İçin Yığın Öğeleri

Peki PHP'ye iletilen istekleri azaltmamıza yardımcı olacak yığın öğeleri nelerdir? Pekala, özellikle iki yığın öğesi bu hedefe ulaşmamıza yardımcı olacak: web sunucusu ve HTTP önbelleği.

Web sunucusu

Zaten web sunucuları hakkında biraz konuştuk. Web sunucusu alanında üç büyük oyuncu vardır:

• Apaçi
• İnternet Bilgi Servisleri (IIS)
• nginx

Birlikte, bunlar İnternet'teki web sunucularının pazar payının %90'ından fazlasını oluşturur. Apache ve nginx'e odaklanacağız. IIS, WordPress'i çalıştırmak için kullanılabilse de, yalnızca Windows için mevcut olduğundan ve çoğu WordPress sunucusu Linux kullandığından yaygın değildir.

Bu bizi Apache ve nginx ile baş başa bırakır. WordPress'in ömrü boyunca Apache önerilen web sunucusu olmuştur. WordPress'i hem bilgisayarda hem de sunucuda çalıştıran LAMP yığınına (Linux, Apache, MySQL ve PHP) sahiptik.

Ama perde arkasında işler değişiyordu. Kasabada yeni bir oyuncu vardı ve adı nginx'ti. Automattic ve WordPress.com bunu 2008'den beri kullanıyor. Yüksek trafiğe sahip web sitelerinin (çoğu WordPress çalıştıran) en büyük yüzdesini çalıştıran web sunucusudur. Bu nedenle, birçok üst düzey barındırma şirketi ve en iyi WordPress ajansları onu web sunucusu olarak kullanır.

Apache kötü bir web sunucusu değil. Çok fazla trafik altında harika çalışmasını sağlayabilecek Apache uzmanları var. Kutudan çıktığı gibi veya standart WordPress yapılandırmasıyla pek iyi sonuç vermiyor.

Bu arada, nginx'in tek amacı çok fazla trafiği idare etmektir. Bu yüzden Igor Sysoev projeye Rambler'de çalışırken başladı.

Nginx'in daha fazla trafiği daha iyi yönetmesinin nedenlerinden biri, PHP ile iletişim kurmak için FastCGI kullanmasıdır. FastCGI nedir? PHP'nin web sunucusundan ayrı bir hizmet olarak çalışmasına izin veren bir protokoldür.

Apache bunu varsayılan olarak yapmaz. Web sunucusu her istek aldığında, resimler, JavaScript ve CSS için bile bir PHP çalışma zamanı süreci başlatması gerekir. Bu, sunucunun işleyebileceği istek sayısını ve bunları ne kadar hızlı işleyebileceğini azaltır.

Bu, daha önce gördüğümüz modern WordPress sunucu yığınının hedeflerinden birine aykırıdır. Yığın, istek-yanıt döngü süresini mümkün olduğunca düşük tutmalıdır. Her istek için PHP'yi yüklemek, ihtiyaç duymadığında bile bu amaca aykırıdır. Bu nedenle, Apache kullanıyorsanız FastCGI'ye bakın.

HTTP/2 , bilmeniz gereken bir diğer önemli web sunucusu özelliğidir. Bu, istek-yanıt döngümüzün tamamına güç veren protokol olan HTTP'nin bir sonraki sürümüdür.

HTTP/2'nin gelmesinden önce, bir tarayıcının web sunucusuyla yalnızca altı bağlantısı olabilirdi. Ve her bağlantı aynı anda yalnızca bir isteği işleyebilir. Bu nedenle, uygulamada, bir istek-yanıt döngüsü, döngü başına altı istekle sınırlandırılmıştır.

Bu gerçek bir problem. Çoğu web sitesinin döngüsünde düzinelerce istek vardır. Geliştiriciler ve sistem yöneticileri bu sınırlamayı aşmanın akıllıca yollarını buldular.

Daha iyi bilinen geçici çözümlerden biri, CSS ve JavaScript dosyalarını birleştirme uygulamasıdır. İdeal bir senaryoda, bu, CSS ve JavaScript dosyaları için toplam istek sayısını ikiye indirir: biri JavaScript için ve diğeri CSS için.

HTTP/2 ile bu gerekli değildir. HTTP/2, bağlantı başına sınırsız sayıda isteğe izin verir. Bu, ilk HTML yanıtından sonraki tüm ekstra isteklerin aynı anda gerçekleşmesine izin verir.

Bunun büyük performans etkileri vardır. Sunucu yığınını optimize etme çalışmalarının çoğu, istek-yanıt döngüsüne odaklanır. Döngü sayısını yalnızca bir avuç kadar azaltarak, HTTP/2 bizim için muazzam miktarda iş yaptı.

HTTP Önbelleği

Modern WordPress sunucu yığınının en önemli kısmı HTTP önbelleğidir. WordPress dünyasında bu sayfaya önbelleğe alma da diyoruz. HTTP önbelleğinin amacı, isteklere verilen yanıtları önbelleğe almaktır. Ne anlama geliyor?

Pekala, önceki örneğimize geri dönelim. Tarayıcı modern.wordpress-stack.org ana sayfası için bir istek gönderir ve web sunucusu bu isteği alır ve PHP'ye iletir.

Bu senaryodaki sorun, web sunucusunun aptal olmasıdır. Aldığı tüm istekleri her zaman PHP'ye iletir - isteklerin çoğunun aynı yanıtı oluşturup oluşturmadığına bakılmaksızın.

Ziyaretçiler oturum açmadığında tam olarak olan budur. Web sunucusuna, hepsi farklı isteklerdir, ancak umurunda değil. Hepsini PHP'ye iletecek ve hepsi için aynı yanıtı üretecektir.

Bu korkunç! Daha önce gördüğümüz gibi, istek-yanıt döngümüzün gerçek darboğazı PHP'dir. Tarayıcınız, ilk ana sayfa yanıtını alana kadar takip isteklerini gönderemez. Web sunucusunun varsayılan olarak her şeyi PHP'ye iletmesini sağlayamayız.

İşte burada HTTP önbelleği devreye girer. Web sunucusu ve PHP arasında bulunur. Görevi, web sunucusunun aldığı her isteği kontrol etmek ve önbelleğe alınmış bir yanıt aramaktır. Eğer yoksa, isteği PHP'ye iletir ve ardından PHP'nin oluşturduğu yanıtı önbelleğe alır.

Bu, istek-yanıt döngü süresini önemli ölçüde azaltır ve web sitesinin daha hızlı yüklenmesini sağlar. Ayrıca web sunucusunun daha fazla eşzamanlı istekleri patlamadan işlemesine olanak tanır.

HTTP Önbelleğinin Farklı Tatları

Bu noktada “Bu bebeği en kısa sürede sunucuma nasıl alabilirim?” diye merak ediyor olmalısınız. İyi haber şu ki, bir WordPress sunucusuna HTTP önbelleği yüklemek oldukça kolaydır. En geniş seçenek yelpazesine sahip bileşendir.

Sayfa Önbelleğe Alma Eklentisi Yükleyin

En kolay yol, bir sayfa önbelleğe alma eklentisi kurmaktır. Aralarından seçim yapabileceğiniz birkaç seçeneğiniz var:

• toplu önbellek
• Hiper Önbellek
• Önbellek Etkinleştirici
• WP Roketi
• WP Süper Önbellek
• W3 Toplam Önbellek

WP Rocket hariç tümü, WordPress dizininde ücretsiz eklentiler olarak mevcuttur. Böylece, bir tane yükleyebilir ve hemen test edebilirsiniz. Bununla birlikte, dört eklentiden en iyisi WP Rocket. Ücretli bir eklenti olsa da, yalnızca bir HTTP önbelleği oluşturmaktan çok daha fazlasını yapar. Bu diğer faydalar, HTTP önbelleğinin yaptığı işi büyütür.

Sayfa Önbelleğe Alma Eklentisi Nasıl Çalışır?

Bu eklentilerin tümü, WordPress'in önbelleğe alma için sunduğu bir eklentiden yararlanır. Bu önbelleğe alma özelliği, eklentilerin WordPress içinde bir HTTP önbellek sistemi oluşturmasını sağlar. Önbelleğe alma açılır penceresinin çalışması için iki şeye ihtiyacı vardır.

İlk olarak, advanced-cache.php açılır dosyasının wp-content klasöründe olması gerekir. Asıl dosya bu. Ancak çoğu WordPress eklentisinin aksine, bu varsayılan olarak devreye girmez. WordPress ayrıca açılır menüyü yüklemek için WP_CACHE sabitinin true olmasına ihtiyaç duyar. Çoğu durumda, bunu wp-config.php içinde ayarlarsınız.

Yukarıdaki şema, bir önbelleğe alma eklentisi ile açılır menüyü etkinleştirdiğinizde ne olduğunu gösterir. WordPress, yükleme işlemi sırasında wp-settings.php içindeki açılır menüyü yükler. Bu, WordPress'in henüz zaman alıcı bir şey yapmadığı süreçte yeterince erken.

Önbelleğe alma eklentisi daha sonra isteğe verilen yanıtı zaten önbelleğe alıp almadığını kontrol edecektir. Varsa, önbelleğe alınmış yanıtı döndürür. Değilse, PHP çıktı arabelleğe almayı açar ve WordPress yüklenmeye devam eder.

Şimdi, çıktı arabelleğe alma ilginç bir sistemdir. Yaptığı şey, iki şeyden biri gerçekleşene kadar bir PHP betiğinin tüm çıktısını bir dize değişkeninde yakalamaktır:

• PHP'ye yerleşik işlevlerden birini kullanarak çıktısını arabelleğe almayı durdurmasını söylersiniz,
• PHP betiği biter ve tarayıcıya bir yanıt döndürmesi gerekir.

Önbelleğe alma eklentisi ikinci senaryoya güveniyor. WordPress'in işini yapmasını ve ardından PHP onu tarayıcıya geri göndermeden önce tüm çıktıyı önbelleğe almasını istiyor. İşlemi aşağıdaki şemada görebilirsiniz.

Web Sunucusunun Yapmasını Sağlayın

Sonraki seçenek, web sunucusu düzeyinde bir HTTP önbelleği eklemektir. Çalışma şekli, web sunucusunun PHP'ye iletilen isteklere verilen tüm yanıtları önbelleğe almasıdır. Bu çözüm bir önbelleğe alma eklentisinden daha iyidir çünkü PHP'ye hiç dokunmasına gerek yoktur.

Yukarıdaki şema, web sunucusunda neler olduğuna dair bir genel bakış sunar. Web sunucusu bir istek alır ve HTTP önbelleği ile kontrol eder. Bir yanıt zaten önbelleğe alınmışsa, HTTP önbelleği bunu geri gönderir.

Aksi takdirde, talebi PHP modülüne iletir (genellikle FastCGI). Bir yanıt oluşturabilmesi için isteği WordPress'e iletir. HTTP önbellek modülü daha sonra bu yanıtı geri dönerken önbelleğe alacaktır.

Hem Apache hem de nginx, bir HTTP önbellek sistemi ekleme özelliğine sahiptir. nginx one yerleşiktir. Apache one, Apache kurulumunuza eklemeniz gereken ayrı bir modüldür.

Apache modülünün PHP veya WordPress ile nasıl kullanılacağına dair çok fazla bilgi yok. Bunun nedeni, Apache kalabalığı arasında popüler olmaması veya bazı sorunları olması olabilir. Hala açık olan en az bir uzun süredir devam eden sorun var.

Bu arada, nginx HTTP önbellek sistemi sağlamdır ve iyi belgelenmiştir. Normal bir HTTP önbelleği olarak veya daha küçük ama etkili bir mikro önbellek olarak kullanabilirsiniz. Bu, nginx'in günümüzde tercih edilen web sunucusu olmasının bir nedeni daha.

Yığına Vernik ekleyin

Vernik nedir? Özel bir HTTP önbellek sunucusudur (veya geliştiricilerinin dediği gibi HTTP hızlandırıcı). Çoğu yüksek trafikli web sitesi ve premium barındırma şirketi, HTTP önbellek çözümü olarak bunu kullanır.

Güçlü olduğu ve en fazla esnekliği sunduğu için kullanıyorlar. Vernik, VCL adı verilen kendi yapılandırma diline sahiptir. Önbelleğe alma işleminin her öğesini kontrol etmenizi sağlar. Vernik ayrıca önbelleğin ne yaptığını ve nasıl performans gösterdiğini analiz etmek için birçok araçla birlikte gelir.

Bunlar, onu kullanmakla yalnızca yerleşik web sunucusu HTTP önbelleğini kullanmak arasındaki temel farklardır. Yerleşik web sunucusu HTTP önbelleği, süper performanslıdır ancak aynı zamanda oldukça basittir. Birkaç yapılandırma seçeneği dışında çok fazla kontrolünüz yok.

Bununla birlikte, bu güç ve esnekliğin bir bedeli vardır. Vernik aynı zamanda en karmaşık HTTP önbellek seçeneğidir. HTTP yanıtlarını önbelleğe almaktan başka bir şey yapmaz. Çoğu WordPress geliştiricisinin istediği (veya istemesi gereken) SSL sonlandırmasını işlemez. Bu, modern WordPress sunucu yığınımızın onu kullandığımızda daha karmaşık olacağı anlamına gelir.

Yukarıdaki diyagram bu ekstra karmaşıklığı göstermektedir. Artık WordPress sunucu yığınımızda iki bileşen daha var: Vernik ve ters proxy.

Ters proxy, Varnish'in SSL ile sahip olduğu sınırlamanın üstesinden gelmek için vardır. Vernik'in önüne oturur ve sunucumuzun aldığı isteklerin şifresini çözer. Bu tür ters proxy'ye SSL sonlandırma proxy'si de diyebilirsiniz. Proxy daha sonra bu şifresi çözülmüş istekleri işlemek için Varnish'e gönderir.

Bir istek Varnish'e ulaştığında, VCL yapılandırma dosyası/dosyaları devreye girer. Onlar Varnish'in beynidir. Örneğin, nasıl yapılacağını söylerler:

• gelen istekleri analiz etmek, temizlemek ve değiştirmek;
• önbelleğe alınmış bir yanıt arayın;
• WordPress'ten gelen yanıtları analiz edin, temizleyin ve değiştirin;
• bu geri dönen yanıtları önbelleğe al;
• önbellekten bir veya daha fazla yanıtı kaldırma isteğini işleyin.

Bu sonuncusu özellikle önemlidir. Kendi haline bırakıldığında, Varnish'in WordPress'in bir sayfayı önbellekten kaldırmak istediğini bilmesinin hiçbir yolu yoktur. Bu nedenle, varsayılan olarak, bir gönderide değişiklik yapıp güncellerseniz, ziyaretçiler aynı önbelleğe alınmış sayfayı görmeye devam eder. Şansımıza, sayfaları Varnish önbelleğinden kaldıran bir eklenti var.

WordPress

Pekala, modern.wordpress-stack.org ana sayfası talebimiz WordPress'e ulaştı. Az önce ele aldığımız istek-yanıt döngüsünden geçti. HTTP önbelleği, geri gönderilecek bir HTTP yanıtı bulmak için elinden gelen her şeyi yaptı.

Ancak tarayıcıya geri gönderilecek önbelleğe alınmış HTTP yanıtı yoktu. Bu noktada, HTTP önbelleğinin başka seçeneği yoktu. HTTP isteğini WordPress'e iletmek zorunda kaldı.

Artık her şey WordPress'in elinde. WordPress, HTTP isteğimizi bir HTTP yanıtına dönüştürmeli ve HTTP önbelleğine geri göndermelidir. Daha önce gördüğümüz gibi, bu, tüm modern WordPress sunucu yığınımızın ana darboğazı.

Bu darboğazın nedeni iki yönlüdür. WordPress'in yürütülecek çok sayıda PHP kodu vardır. Bu zaman alıcıdır ve PHP bunu ne kadar yavaş yaparsa, o kadar uzun sürer.

Diğer darboğaz, WordPress'in gerçekleştirmesi gereken veritabanı sorgularıdır. Veritabanı sorguları pahalı işlemlerdir. Ne kadar çok olursa, WordPress o kadar yavaşlar. Bu, sorgu-sonuç döngüsündeki son bölümün odak noktası olacaktır.

PHP Çalışma Zamanını Optimize Etme

PHP'ye geri dönelim. Şu anda, WordPress'in minimum PHP 5.2 gereksinimi vardır. PHP'nin bu sürümü neredeyse 10 yaşında! (PHP ekibi 2011'de desteklemeyi bıraktı.)

PHP ekibi bunca yıldır boş boş oturmadı. Özellikle son birkaç yılda çok sayıda performans iyileştirmesi yapılmıştır. Bugünlerde optimize etmek için neler yapabileceğinize bakalım.

PHP'nin En Son Sürümünü Kullanın

Yapabileceğiniz en kolay şey PHP sürümünüzü yükseltmektir. 5.4, ​​5.5 ve 5.6 sürümlerinin tümü performans iyileştirmeleri gördü. En büyük gelişme 5,3'ten 5,4'e çıktı. Buna geçmek, WordPress'in performansını iyi bir miktarda artırdı.

Opcode Önbelleğe Alma Kurulumu

Opcode önbelleğe alma, PHP'yi hızlandırmanın başka bir yoludur. Sunucu taraflı bir betik dili olarak PHP'nin büyük bir kusuru vardır: Her çalıştırıldığında bir PHP betiğini derlemesi gerekir.

Bu sorunun çözümü derlenmiş PHP kodunu önbelleğe almaktır. Bu şekilde, PHP her çalıştırıldığında onu derlemek zorunda kalmaz. Bu, opcode önbelleğinin işidir.

PHP 5.5'ten önce, PHP bir işlem kodu önbelleği ile birlikte gelmiyordu. Sunucuya kendiniz yüklemeniz gerekiyordu. PHP'nin daha yeni bir sürümünü kullanmanın daha iyi olmasının bir başka nedeni de budur.

Yeni Nesil Derleyiciye Geçin

Yapabileceğiniz son şey, yeni nesil iki derleyiciden birine geçmek: Facebook'un HHVM'si veya PHP'nin en son sürümü olan PHP 7. (Neden PHP 7? Bu uzun bir hikaye.)

Facebook ve PHP ekibi bu iki derleyiciyi sıfırdan oluşturdu. Daha modern derleme stratejilerinden yararlanmak istediler. HHVM tam zamanında derlemeyi kullanırken PHP 7 önceden derlemeyi kullanır. Her ikisi de eski PHP 5'e göre inanılmaz performans iyileştirmeleri sunar.

Birkaç yıl önce olay yerine ilk ulaşan HHVM oldu. Birçok üst düzey ana bilgisayar, onu birincil PHP derleyicileri olarak sunarak çok başarılı oldu.

Yine de HHVM'nin resmi bir PHP derleyicisi olmadığını vurgulamakta fayda var. PHP ile %100 uyumlu değildir. Bunun nedeni, HHVM'nin yalnızca PHP'yi desteklemek için tasarlanmamasıdır; aynı zamanda Facebook'un Hack programlama dili için bir derleyicidir.

PHP 7, resmi bir PHP derleyicisidir. Uzun zamandır ortalıkta yok. PHP ekibi onu Aralık 2015'te yayınladı. Bu, bazı WordPress barındırma şirketlerinin onu desteklemesini engellemedi.

İyi haber şu ki, WordPress'in kendisi her iki derleyiciyle de %100 uyumludur! Kötü haber şu ki, tüm eklentiler ve temalar böyle değil, çünkü WordPress için minimum PHP sürümü hala 5.2.

Hiçbir şey yazarları eklentilerini veya temalarını bu derleyicilerle çalışmaya zorlamaz. Yani, bunlardan biriyle giremezsiniz. Yığınınız her zaman PHP 5'e geri dönmelidir.

Sorgu-Sonuç Döngüsü

Bu noktada, PHP çalışma zamanı tüm WordPress PHP dosyalarından geçiyor ve onları çalıştırıyor. Ancak, bu WordPress PHP dosyaları herhangi bir veri içermez. Yalnızca WordPress kodunu içerirler.

Sorun, WordPress'in tüm verilerini bir MySQL veritabanında depolamasıdır. Bu nedenle, buna ulaşmak için PHP çalışma zamanının bu veritabanını sorgulaması gerekir. MySQL sunucusu bu sorgunun sonucunu döndürür ve PHP çalışma zamanı daha sonra WordPress PHP dosyalarını yürütmeye devam eder… yani, yeniden veriye ihtiyaç duyana kadar.

Bu ileri geri birkaç düzineden birkaç yüz defaya kadar olabilir. (Sonuncusuysa geliştiricinizle konuşmak isteyebilirsiniz!) Bu yüzden büyük bir darboğaz.

Sorgu-Sonuç Döngüsünü Optimize Etme

Buradaki optimizasyon amacı, PHP tarafından WordPress dosyalarının yürütme süresini hızlandırmaktır. Veritabanı sorgularının sorunlu olduğu yer burasıdır. Sadece düz PHP kodu çalıştırmaktan daha fazla zaman alırlar (kodunuz aşırı bir şey yapmıyorsa).

Bu sorunu çözmenin bariz yolu, WordPress'in gerçekleştirmesi gereken sorgu sayısını azaltmaktır. Ve bu her zaman faydalıdır! Ancak bu, modern WordPress sunucu yığınının yardımcı olabileceği bir şey değil.

WordPress'in yaptığı sorgu sayısını azaltamayabiliriz, ancak seçeneklerimiz de bitmedi. Yığının, sorgu-sonuç döngüsünü optimize etmemize yardımcı olmasının hala iki yolu vardır. İlk etapta veritabanına yapılan sorgu sayısını azaltabilir. Ve veritabanına ulaşan sorgular için, onları çalıştırmak için gereken süreyi azaltabilir.

Bu iki seçeneğin ikisi de aynı şeyi yapmak içindir: PHP'nin veritabanından gelen sonuçları mümkün olduğunca az beklemesini sağlayın, bu da WordPress'in kendisini daha hızlı hale getirecektir.

Sorgu-Sonuç Döngüsü İçin Yığın Öğeleri

Sorgu-sonuç döngüsünde yer alan farklı yığın öğelerine bakalım. Yığının bu kısmı daha az karmaşıktır. Ancak yine de birden fazla bileşen içerir - yani, MySQL veritabanı sunucusu ve nesne önbelleği.

MySQL Veritabanı Sunucusu

Birkaç yıl önce, bir MySQL veritabanı sunucusu herkes için aynı anlama gelirdi. MySQL sunucusunun kurulu olduğu bir sunucuydu. Ama son yıllarda işler çok değişti.

Çeşitli gruplar Oracle'ın MySQL projesini yönetme şeklinden memnun değildi. Böylece, her grup onu çatalladı ve onun yerine “düşebileceğiniz” kendi versiyonunu yarattı. Sonuç olarak, artık birkaç MySQL veritabanı sunucusu var.

Yeni "resmi" MySQL sunucusu, MariaDB sunucusudur. MySQL sunucusunun topluluk tarafından geliştirilmiş versiyonudur. Topluluk, MySQL sunucu projesiyle tam uyumluluğu korumayı planlıyor.

MySQL'in bir diğer popüler alternatifi Percona sunucusudur. MariaDB'den farklı olarak, Percona daha çok MySQL'in bir dalıdır. Geliştiricileri MySQL projesinin kendisine karşı değiller; sadece MySQL'in performansını geliştirmeye odaklanmak istiyorlar. MariaDB ekibi daha sonra bu performans iyileştirmelerinden bazılarını MariaDB projesinde birleştirdi.

Günün sonunda, tercih ettiğiniz birini seçebilirsiniz. Bir Percona sunucusu ile bir MariaDB sunucusu arasında performans açısından hiçbir fark yoktur (her nasılsa çoğumuz için). İkisi de MySQL'den daha iyi performans gösteriyor. Ancak Percona, Oracle projesiyle daha yakın uyumluluk sağlar.

Performansı etkileyen şey, WordPress veritabanının kullandığı depolama motorudur . Depolama motoru, veritabanı sunucusunun depoladığı verileri nasıl yönettiğini kontrol eder. Ayrıca her veritabanı tablosu için farklı bir depolama motoru ayarlayabilirsiniz; tüm veritabanı için aynı olanı kullanmak zorunda değilsiniz.

Bir veritabanı sunucusunun birkaç depolama motoru vardır. Hepsine bakmayacağız. Sadece ikisi bizi ilgilendiriyor: InnoDB ve MyISAM.

Varsayılan olarak, WordPress varsayılan MySQL veritabanı motorunu kullanır. MySQL 5.5'ten önce bu motor MyISAM'dı. Küçük bir WordPress web sitesi işletiyorsanız, MyISAM iyidir. MyISAM, bir web sitesi büyüdüğünde performans sorunlarıyla karşılaşır. Bu noktada, InnoDB bir veritabanı motoru için tek seçenektir.

InnoDB ile ilgili tek sorun, en iyi performansı göstermesi için biraz ayarlama gerektirmesidir. Büyük bir veritabanı sunucusu çalıştırıyorsanız, bazı şeyleri ayarlamanız gerekebilir. Neyse ki bizim için buna yardımcı olacak bir araç var.

MySQLTuner, veritabanı sunucunuzu analiz eden küçük bir komut dosyasıdır. Bir rapor oluşturacak ve size ayar önerileri verecektir.

Nesne Önbelleği

Sorgu-sonuç döngüsünü optimize etme işinin yükü, nesne önbelleğine aittir. Nesne önbelleğinin işi, alınması veya üretilmesi zaman alan verileri depolamaktır. Tahmin edebileceğiniz gibi, veritabanı sorguları mükemmel bir adaydır.

WordPress, nesne önbelleğini çok kullanır. Veritabanından bir seçenek almak için get_option kullandığınızı varsayalım. WordPress, bu seçenek için veritabanını yalnızca bir kez sorgulayacaktır. Bir dahaki sefere birinin ihtiyacı olduğunda tekrar sorgulamaz.

Bunun yerine, WordPress, sorgu sonucunu nesne önbelleğinden alır. Bu, WordPress'in yapması gereken veritabanı sorgularının sayısını azaltmak için attığı proaktif bir adımdır. Ama kusursuz bir çözüm değil.

WordPress, nesne önbelleğinden yararlanmak için elinden gelenin en iyisini yapacak olsa da, bir eklenti veya temanın buna ihtiyacı yoktur. Bir eklenti veya tema çok sayıda veritabanı sorgusu yapıyorsa ve sonuçları önbelleğe almıyorsa, yığın bu konuda hiçbir şey yapamaz.

Bu gibi durumlarda, veritabanı sorgularının çoğu WordPress'in kendisinden gelecektir. Böylece, WordPress'in nesne önbelleğini yerleşik kullanımından büyük fayda elde edeceksiniz. Bu nedenle modern WordPress sunucu yığınının önemli bir öğesidir.

Şimdi, nesne önbelleğiyle ilgili bir sorun, varsayılan olarak depoladığı verileri sürdürmemesidir. PHP tüm WordPress dosyalarını yürütürken verileri yalnızca bellekte depolar. Ancak PHP işlemi sona erdiğinde, bellekte depoladığı tüm veriler temizlenir.

Bu hiç ideal değil. Bir nesne önbelleği uzun süre geçerli kalabilir, bu nedenle onu tek bir istekle sınırlamak istemezsiniz. Çözüm, kalıcı bir nesne önbelleği kullanmaktır .

Kalıcı bir nesne önbelleği genellikle bir eklenti biçiminde gelir. Bu eklenti, işini yapmak için object-cache.php açılır listesini kullanır. Bu açılır menü, eklenti yazarlarının nesne önbelleğinin varsayılan davranışını değiştirmesine izin verir.

Eklentiler daha sonra nesne önbelleğini kalıcı bir veri deposuna bağlar. Bunu, varsayılan nesne önbelleğinin getirme ve kaydetme işlevini değiştirerek yaparlar. Verileri belleğe kaydetmek ve almak yerine, nesne önbelleği bunu o depodan yapar.

Kalıcı Nesne Önbelleği Eklentileri

Günümüzde kalıcı nesne önbelleğe alma için iki popüler veri deposu seçeneği vardır:

• Memcached (eklenti)
• Redis (eklenti)

Bu veri depolarının her ikisi de depolama için RAM kullanır ve bu da onları yıldırım hızında yapar. Aslında, performansları varsayılan nesne önbelleğinin performansıyla karşılaştırılabilir.

Tek sorun, sunuculara önceden yüklenmiş olarak gelmemeleridir. Ve onların PHP uzantısı da (Redis ile isteğe bağlıdır) değildir. İlgili WordPress eklentisini kullanmadan önce bir tane yüklemeniz gerekir.

Hangisini yüklemelisiniz? Pratikte, nesne önbelleğe alma için ikisi arasında pek bir fark yoktur. Geçmişte popüler seçenek Memcached idi. Bu son birkaç yılda değişti. Redis, onu nesne önbelleğe alma için tercih edilen seçenek haline getiren birçok özellik ekledi.

Kendi Modern WordPress Sunucunuzu Edinme

Peki, kendi sunucunuzu nasıl alırsınız? Açık yol, üst düzey bir WordPress barındırma şirketinden bir tane almaktır. Bu şirketler, onları en son buluşları ve teknolojileri benimsemeye motive eden WordPress barındırma işinde ön saflarda kalmak istiyor.

Ama ya bankayı bozmadan bir tane istersen? Kendileri yapmayı ve barındırma için daha az ödeme yapmayı tercih eden herkes için birkaç araç mevcuttur. Onlara bir bakalım.

WordPress için DebOps

WordPress için DebOps, herkesin modern bir WordPress sunucusu oluşturmasına yardımcı olmak için oluşturduğum bir araçtır. Misyonu, modern WordPress sunucu yığınını topluluktaki herkesin kullanımına sunmaktır. Bu yüzden mümkün olduğunca kullanımı kolay hale getirmeye çalışıyorum. Kullanmak için herhangi bir sistem yönetimi bilgisine ihtiyacınız yoktur.

WordPress için DebOps, bir sunucuyu aşağıdakilerle yapılandırır:

• HHVM (PHP 7 onu resmi bir Linux deposu haline getirene kadar)
• MariaDB
• nginx
• redis
• vernik

Araç, en son teknolojilere sahip bir sunucuyu yapılandırmaktan fazlasını yapar. Ayrıca sunucuyu sizin için güvence altına almakla da ilgilenir. Bu, insanların kendi sunucularını yönetirken sıklıkla gözden kaçırdıkları bir şeydir.

EasyEngine

EasyEngine, bir sunucuda WordPress web sitesi kurmanıza yardımcı olmak için tasarlanmış bir komut satırı aracıdır. EasyEngine ile ilgili en iyi şey esnekliğidir: Şimdiye kadar incelediğimiz hemen hemen her türlü sunucu teknolojisi kombinasyonunu kurmak için kullanabilirsiniz.

Örneğin, HHVM veya PHP 7 ile bir sunucu kurmanıza izin verir. Kalıcı veri deponuz için Memcached ve Redis arasında seçim yapmanızı sağlar. Ve phpMyAdmin gibi yönetici araçlarını kurmanıza izin verir.

Ayrıca bir WordPress web sitesi oluşturduğunda çok sayıda seçenek sunar. Bir eklenti veya nginx kullanarak HTTP önbelleği olan bir web sitesi kurmasını söyleyebilirsiniz. Tüm bu esneklik, EasyEngine'in bu kadar popüler bir araç olmasının nedenidir.

Çardak

Trellis, Roots tarafından geliştirilen bir araçtır. DebOps gibi, sunucuyu belirli bir dizi sunucu teknolojisiyle yapılandırır:

• MariaDB
• önbelleğe alınmış
• nginx
• nginx HTTP önbelleği (isteğe bağlı)
• PHP 7

Trellis hakkında bilinmesi gereken bir şey, Roots tarafından geliştirilen bir başka araç olan Bedrock ile olan ilişkisidir. Bedrock, bir WordPress web sitesini “On İki Faktör Uygulaması” ilkeleri etrafında yapılandırmak için bir kalıptır.

Roots ekibi, insanların Bedrock yapılı WordPress web sitelerini kullanan bir sunucu yapılandırmasını sağlamak için Trellis'i yarattı. Normal bir WordPress kurulumuyla kullanamazsınız, bu yüzden bunu aklınızda bulundurun.

Zaman değişti

Gördüğünüz gibi, bir WordPress sunucusunun bugün çok daha fazla hareketli parçası var! Ancak bunun umutsuzluk için bir neden olması gerekmez. Göründüğü kadar kötü değil çünkü her zaman tüm parçaları kullanmanıza gerek yok.

Bu yüzden bu makalenin çoğu bu parçaların birlikte nasıl çalıştığını tartışıyor. Buradaki amaç, kendi kararlarınızı vermeniz için size yetki vermektir. Hangi parçaları ne zaman kullanmanız gerektiğine karar vermek için bu bilgiyi kullanın. Bu sayede siz de hızlı bir WordPress web sitesine sahip olacaksınız.