CMS Felaketinden Kaçınmak: Web Sitesi Kapalı Kalma Süresini Nasıl Önlersiniz?

Bir sitenin kapalı sayılması aslında ne anlama geliyor ?

Çoğu zaman bu, kime sorduğunuza bağlıdır.

Bir web sitesinin olumsuz olarak değerlendirilmesi birkaç farklı anlama gelebilir:

• Web sitesi tamamen kullanılamıyor.
• Web sitesi çevrimiçi ancak kullanılamayacak kadar yavaş.
• Web sitesi belirli kullanıcılar veya konumlar için hata mesajları veriyor.
• Web sitesi çoğu ziyaretçi için çalışıyor, ancak bazıları örneğin içerik oluşturmak, düzenlemek veya yayınlamak için CMS'lerinde oturum açamıyor.

Nedeni veya derecesi ne olursa olsun, web sitesi kesinti süresinin etkisi, kaybedilen e-ticaret siparişlerinden ve hüsrana uğramış kullanıcılardan zayıflamış müşteri güvenine kadar ciddi olabilir.

CMS Felaketinden Kaçınma serimizin üçüncü bölümünde, web sitesi kapalı kalma süresinin klasik temel nedenlerini ve sürekli izlemenin ve diğer faktörlerin bundan kaçınmada oynadığı rolü araştırıyoruz.

Birincisi, sürekli izlemenin oynadığı rol

Bir web sitesinin farklı yönlerini izliyoruz, böylece tam olarak yönetilen WordPress VIP platformumuzu oluşturan farklı katmanlardan herhangi birinde bir şeyin doğru çalışmadığını anlayabiliriz. Bu katmanlar şunları içerir:

• ağ bağlantısı
• Yük Dengeleyiciler
• Web sunucuları
• Nesne önbelleğe alma (Memcached)
• veritabanları
• Elasticsearch
• Dosya Hizmeti (CDN)

Web sitesi kararlılığını etkileyebilecek gelecekteki sorunları tahmin edebilmemiz için sorunları erkenden tespit etmeye çalışıyoruz. Farklı sistem bileşenlerinden gelen çapraz referans günlükleri, bir web sitesinin kararsız olarak bildirildiği dönemleri incelememize olanak tanır. Arıza süresinden tek bir sorundan ziyade faktörlerin bir kombinasyonu sorumlu olabileceğinden, hem sistemlerde hem de uygulamalarda verileri karşılaştırmak için bir dizi araç kullanıyoruz.

Çoğu durumda, web sitesi kararsızlığı, uygulama kodunun, yani özel veya üçüncü taraf WordPress temasının ve eklenti kodunun bir sonucudur. Kararsız bir siteyi araştırırken aradığımız birkaç şey ve her birinin nasıl azaltılacağı aşağıda açıklanmıştır.

Yeterli önbellek yok

Bir sitenin performanslı ve istikrarlı olmasını sağlamak için yapabileceğiniz en önemli şey, önbelleğe alınabilecek tüm sayfaların önbelleğe alındığından emin olmaktır. Önbelleğe alınmamış sayfaların, her istendiğinde sunucuda oluşturulması gerekir; bu, daha yavaş bir işlemdir ve hatalara daha yatkındır.

WordPress VIP yanıtı:

WordPress VIP Platformu, her biri son kullanıcıya en yakın içeriği depolamak ve sunmak için kullanılan küresel bir uç önbellek sunucuları ağı aracılığıyla güçlü sayfa önbelleğe alma sağlar. Bir uç önbellek sunucusundan gelen yanıt süresi, sayfa önbelleğe almayı atlayan ve kaynak sunuculara ulaşan herhangi bir şeyden neredeyse her zaman çok daha hızlıdır.

Önbelleğe alma zorlukları

Kişiselleştirilmiş, tamamen etkileşimli bir deneyim talep ettikleri için bazı siteler, özellikle e-ticaret siteleri, sayfa önbelleği düzeyinde önbelleğe alınamaz.

Çoğu zaman, JavaScript aracılığıyla eklenen dinamik özelliklerle (ör. oturum açma durumu, alışveriş sepetleri) statik bir sayfanın uç önbellek tarafından sunulduğu bir uzlaşma bulunabilir. JavaScript'ten gelen eşzamansız istekler daha sonra tam sayfa yüklemesinden çok daha düşük bir ek yük ile tasarlanmış bir WordPress REST API uç noktası ile iletişim kurmak için kullanılabilir.

Alternatif olarak, nesne önbelleğe almanın devreye girdiği yer burasıdır. Sayfa dinamik kalabilir, ancak sayfanın bölümleri ve içinde kullanılan herhangi bir veri, veritabanını sorgulama ihtiyacından kaçınmak için nesne önbelleğinde saklanabilir ve alınabilir.

WordPress VIP yanıtı:

Her WordPress VIP uygulama ortamının, ışık hızında ve verimli bir şekilde alınması için nesne önbellek verilerini bellekte saklayan kendi özel Memcached kümesi vardır.

Test edilmemiş kod dağıtımları

Bu, web sitesinin kapalı kalma süresinin bir başka yaygın suçlusudur ve saf neden ve sonuca dayalı olarak teşhis edilmesi oldukça kolaydır.

Web siteniz henüz test edilmemiş kod dağıttıysa ve anında site sorunlarına yol açtıysa, bunun olası nedeni budur. Mümkünse, şüpheli kodu en kısa sürede önceki sürüme döndürün.

Bu durumdan kaçınmak için yapılacak en iyi şey? Üretime sunmadan önce her bir kod parçasını ayrı bir geliştirme veya hazırlama ortamında iyice test edin.

WordPress VIP yanıtı:

Tüm site dağıtımlarımız GitHub üzerinden yapıldığından, WordPress VIP müşterileri, GitHub revizyon geçmişinde güvenli bir şekilde saklanan yeni kod değişikliklerini kaybetmeden kodu kendilerini kolayca geri alabilirler. İsteğe bağlı olarak, acil durumlarda, bir müşterinin web sitesini GitHub'dan bağımsız olarak onlar adına önceki bir dağıtıma geri alabiliriz.

Ortamlarla ilgili olarak, tam olarak yönetilen hizmetimizde barındırılan tüm uygulamaların ayrı bir geliştirme veya hazırlama ortamı olabilir. Orada üretimden verileri senkronize etmek kolaydır, bu da kodu üretim web sitenizdekiyle aynı miktarda ve aynı türde verilerle test etmenize olanak tanır.

PHP hataları

WordPress, sunucuda PHP kodunu kullanır. Bir PHP hatası "ölümcül" olabilir, yani hata oluştuğunda web sayfası, komut dosyası veya komutun çalışması duracaktır. Bunlar neredeyse her zaman bir yerlerde görünür hatalar olarak ortaya çıkacak ve PHP günlüklerine kaydedilecektir.

Not: PHP 7'deki bazı PHP uyarıları PHP 8'de ölümcül hatalara dönüşür, bu yüzden bu hataları ciddiye almak önemlidir.

WordPress VIP yanıtı (ayrıca faydalı tavsiyeler):

Platformumuz tüm PHP hatalarını otomatik olarak günlüğe kaydeder ve bunları panolarında WordPress VIP müşterilerinin ve mühendislerimizin kullanımına sunar.

Profesyonel ipucu : Bir site iyi çalışıyor gibi görünse bile tüm PHP hatalarını giderin ve düzeltin. Rutin olarak, kararlı görünen bir sitede PHP hatalarıyla, hatta ölümcül olanlarla dolu günlükler görürüz. Ancak bu, sitenin doğru çalıştığı anlamına gelmez. Küçük hataları ve uyarıları ele alarak PHP günlüklerini temiz tutmak, hata ayıklama sırasında daha ciddi hataları bulmayı kolaylaştırır.

Yavaş MySQL veritabanı sorguları

Her WordPress web sitesi, web sitesi içeriğini ve yapılandırma verilerini depolamak için bir veritabanı kullanır. Veritabanı sorguları, web sayfaları için bu içerik verilerini getirir, ancak bazen bu sorgular verimsiz bir şekilde yazılır. Yalnızca birkaç yüz sayfası olan siteler için iyi çalışabilirler, ancak büyük miktarda veri işlerken dururlar (platformumuzdaki bazı web sitelerinde milyonlarca kayıtlı kayıt vardır).

Yavaş bir sorgu, veritabanı kaynaklarını birbirine bağlar ve yalnızca SQL'i çalıştıran sayfa, komut dosyası veya komut için değil, tüm uygulama genelinde site kararlılığını potansiyel olarak etkiler. Siteler genellikle tekli veya çoklu veritabanı sorguları yavaş olduğundan, örneğin yürütülmesi 0,75 saniyeden uzun süren herhangi bir sorguda sorun yaşar.

WordPress VIP yanıtı:

WordPress VIP, her uygulamaya, tüm veritabanı yazma sorgularının gerçekleştiği bir birincil veritabanı ve bir veya daha fazla salt okunur çoğaltma veritabanı içeren özel bir veritabanı kümesi sağlayarak veritabanı darboğazlarını azaltmaya yardımcı olur. Bu, bir site baskı altındayken kaynak yükünü yayarak gerçekleşebilecek eşzamanlı veritabanı sorgularının sayısını artırır. Bununla birlikte, yavaş veritabanı sorguları her zaman ek veritabanı kaynakları ekleyerek çözülemez. Bu nedenle müşterilerimize Query Monitor ve New Relic (platformumuz tarafından sağlanır) kullanarak yavaş veritabanı sorgularını izlemelerini tavsiye ediyoruz. Bunlar, sorguların veritabanında nereden kaynaklandığını vurgular, böylece geliştirme ekibiniz performansı optimize etmek için bunları yeniden düzenleyebilir.

Son olarak, Uygulama Desteğimiz ve Premier Mühendislerimiz de ekibinizin bu sorguları bulmasına ve analiz etmesine yardımcı olabilir ve bunları hız ve verimlilik için iyileştirmenin yollarını önerebilir.

Aşırı veritabanı yazma

Bazen özel günlük kaydı veya izleme kodu gibi bir özellik, her istekte veritabanını günceller. Bu, iki nedenden dolayı istikrarsızlığa yol açabilir:

• Yukarıdaki veritabanı replikaları : Tüm yazma sorguları birincil veritabanına yönlendirilir; aynı sayfa isteğindeki aynı tablo (veya tablolar) için sonraki veritabanı sorguları da oraya yönlendirilecektir. Veritabanı replikalarından yararlanmamak, sitenin ölçeklenebilirliğini sınırlar.
• Sayfa önbelleğe almayı atlama : Her sayfa isteğinde bir veritabanı yazma işleminin gerçekleşmesi için sayfa önbelleğe alma işleminin atlanması gerekir. Ancak bunu yapmak, ilk (ve en iyi) savunma hattının tehlikeye atıldığı anlamına gelir.

WordPress VIP yanıtı:

Bu durumlarda, özelliği yeniden düzenlemenizi öneririz. Örneğin, içerik analizi genellikle en iyi şekilde, sunucu tarafı kodu yerine sayfada JavaScript snippet'i kullanan, önbelleğe alma ile iyi çalışmayan ve aşırı veritabanı yazma işlemlerine neden olabilen harici bir hizmete devredilir.

Arıza süresinin bilinen diğer nedenleri ve bunlardan nasıl kaçınılacağı

Eklentiler

WordPress ekosisteminde harika özellikler ve işlevsellik sağlayan binlerce popüler, yardımcı üçüncü taraf eklentisi vardır. Bununla birlikte, bazıları, tonlarca içerik ve trafiğe sahip bir web sitesine eklendiğinde potansiyel olarak kesinti sorunlarına yol açan ölçeklendirme zorluklarına sahiptir.

WordPress VIP yanıtı:

İyi ekosistem görevlileri olarak, eklentilerinin yüksek trafikli ortamlarda daha iyi performans göstermesini sağlamak için satıcılara düzenli olarak önerilerde bulunuyoruz. Platformumuzda geniş ölçekte denenmiş ve test edilmiş alternatif eklentiler de önerebiliriz.

Özel günlük kaydı

Özel günlük kaydı, güçlü bir hata ayıklama aracıdır ve genellikle yalnızca bir üretim sitesinde meydana gelen bir hatayı veya sorunu izlemenin tek geçerli yöntemidir. Bununla birlikte, birçok durumda, yüksek trafikli bir sitede PHP'de yerleşik özel günlük kaydının işleri yavaşlattığını veya aşırı veritabanı yazma işlemleri nedeniyle bir siteyi kesinti tehlikesiyle karşı karşıya bıraktığını gördük.

WordPress VIP yanıtı:

Müşteriler için, WordPress VIP Uygulama Panosu'nun Sağlık panelindeki standart PHP günlüklerine erişim sağlıyoruz. Orada veritabanını olumsuz etkilemeyecek özel hataları (ve ayrıca New Relic'e) kaydedebilirler.

Uzak API çağrıları

Bazı web siteleri, diğer uygulamalara veya hizmetlere sunucu tarafı REST API çağrılarından yararlanır. Bunlar normal koşullar altında oldukça hızlıdır, ancak bazen temeldeki uygulama kodu yavaş yanıta, zaman aşımına veya bir hataya neden olur.

WordPress VIP yanıtı:

Bu sorunları en aza indirmek için “savunma kodlaması” öneriyoruz. Uzak aramanın amacına bağlıdır, ancak genellikle bir uzak istek başarısız olduğunda, önceki bir istekten gelen önbelleğe alınmış bir yanıta geri dönmek veya en azından sayfanın geri kalanının bunu yapabilmesi için "hatayı zarif bir şekilde ele almak" mümkündür. hala yük. Bu senaryoları işlemek için bir dizi yardımcı işlev sağlıyoruz. Zaman aşımını düşük tutmak, uzak API yanıt vermiyorsa PHP kaynaklarının daha hızlı boşaltılması anlamına gelir.

CMS Felaketinden Kaçınma serimizde daha fazlasını okuyun

İşletmeniz tehlikedeyken, içerik yönetim sisteminizin (CMS) kötü bir dijital deneyim sunmasını sağlayarak başka bir yere yeni iş göndermeyi ve markanızı lekelemeyi göze alamazsınız. Web Sitesi Performansı Nasıl İyileştirilir 'de, beş yaygın yavaşlama suçlusunu ve çevik bir CMS kullanarak işleri nasıl turboşarj edeceğinizi teşhis ediyoruz.

Yoğun trafikli günler kutlama için bir neden olmalı, bir siteyi ve uygulamaları çalışır durumda tutmaya çalışan ve yükü ve itibarınızı korumak için uğuldayan mühendisler için bir kabus değil. Yüksek Trafik için WordPress'i Ölçeklendirme bölümünde, bir WordPress web sitesinin bu trafik gelgit dalgalarını yönetmesini sağlamaya yönelik dört yaklaşımı keşfediyoruz.