WordPress sunucumuzda yüksek cpus kullanımının faillerini bulun

Yüksek CPU kullanım bölümü sırasında web sitesi istatistiklerimiz.
Bugün, web sitesinde oldukça yaygın sorunlarla başa çıkma, suçluyu tanımlamak için ne yaptığımızı ve sorunu nasıl çözdüğümüzü açıklama konusundaki deneyimimizi paylaşmak istiyoruz. Bu şekilde, aynı sorunla karşılaşırsanız, nasıl başlayacağınız hakkında bazı fikirleriniz olacak …
CPU WordPress’i yüksek kullanabilmenizin nedeni, PHP’de yazılmış bir içerik yönetim sistemidir. Bu, hizmet verdiği içeriğin bir dizi PHP komut dosyası tarafından dinamik olarak üretildiği anlamına gelir: Bir ziyaretçi web sitenize her geldiğinde, WordPress işlem istekleri (kabaca “ana sayfanızı gönder” gibi) ve bir yanıt üretir (bu durumda, bu ana sayfa gönderir). Açıkçası, taleplere yanıt vermek belirli sunucu kaynaklarının kullanımını ima eder: bir kişi isteğin kendisine bakmalı, ziyaretçinin neye erişmek istediğini belirlemeli, veritabanından almalı, bir HTML yanıtı ile sonuçlanmalıdır.
Önbellek sisteminin web sitenizin yükleme süresini hızlandırmasının nedenlerinden biri şimdi oldukça açık olmalıdır: temel olarak bu işlem süresini kaydeder. Özel bir istek ilk kez geldiğinde (“Bana ana sayfanızı gönder”), WordPress başladı ve bir yanıtla sonuçlandı. Bir önbellek varsa, ziyaretçilere gönderilmeden önce yanıtı tutar. Bu şekilde, aynı kaynaklara (örneğimizde ana sayfalar) gelecekteki taleplerin artık hiçbir şeyi işlemek için WordPress’e gerek yoktur; Önbellek, daha önce saklanan bir kopyayı geri gönderebilir, böylece zaman ve kaynaklardan tasarruf edebilir. Bu performansı göz önünde bulundurarak, sunucumuzda yüksek CPU’ların kullanımını görebilmemizin nedeni ne olduğunu hayal etmek zor değildir:
Çok fazla istek alıyorsunuz. Birçok kullanıcı web sitenizi aynı anda ziyaret ederse veya birçok geçersiz istek alırsanız (birisi sunucunuza saldırabilir), WordPress tüm bu istekleri işlemelidir ve bu nedenle sunucu kaynaklarının kullanımı artacaktır.
Yavaş talep tamamlanacak. Yüklü çok sayıda eklenti varsa veya eklentilerinizin bir kısmı herhangi bir nedenle verimsizse, aldığınız tüm istekler gerekenden daha uzun sürecektir, çünkü WordPress birçok verimsiz kod çalıştıracaktır.
Yani önbellek bu sorun için iyi bir koruma gibi görünüyor, değil mi? Ve gerçekten de. Ancak, önbelleğin sorunu “geliştirmediğini” lütfen unutmayın; Bu sadece “saklanıyor”. Ve bu hatırlamak önemlidir, çünkü önbellek olamayacak ve bu nedenle her zaman çalıştırmak için WordPress’e ihtiyaç duyacak WordPress işlevselliği vardır: görevin WP-CRON kullanması planlanıyor. WP-CRON, gelecekte çalışacak görevleri planlamak için bir WordPress mekanizmasıdır. Örneğin, WordPress bunu planlanan yayınları yayınlamak için kullanır.
WordPress API REST. REST API, JSON nesneleri göndererek ve alarak WordPress sitesiyle etkileşime girmesi için üçüncü taraf uygulamalarından biri tarafından kullanılabilecek bir arayüzdür. Bazı restoran istekleri önbellek olabilir (yani, talep edin), ancak diğerleri (post ve koyma) değildir. Bu nedenle, bu genellikle önbellek alamayacağınız bir şey …
WordPress’te Ajax isteği. WordPress’te yangın dinlenmeden önce, dinamik bir web sitesi oluşturmak için Ajax API’sını kullanmalıyız. Bu API yangın dinlenmesine çok benzer, çünkü sunucudan bilgi göndermek ve almak için de kullanabiliriz. Bu farklı bir sistemdir, ancak API REST ile aynı sınırlara tabidir.
İlk sorunu analiz ederek, CPU kullanımının web sitemizde neden arttığını belirlemeliyiz. Web sitemize olan talep miktarı artıyor mu? Bireysel taleplere hizmet etmek şimdi daha yavaş mı? Bu soruyu cevaplamak için sunucumuzda çok kullanışlı bir araç var: günlük erişimi.
Erişim günlüğü, sunucunun aldığı her isteği bu konuda yararlı bilgilerle birlikte kaydettiği bir metin dosyasıdır. Özellikle, erişim günlüğü, isteğin ne zaman alındığını (tarih ve saat), bunu yapan (IP), hangi kaynakların istendiğini (URL), isteğin başarılı olup olmadığı vb. Aşağıdakiler sunucumuzun bir örneği: 66.249.83.82-[22/nis/2020: 14: 04: 59 +0200] “GET/ES/Blog/Imagenes-Gratuity-Para-TU-Blog/HTTP/1.0” 200 22325 “-” “Mozilla/5.0 (Linux; Android 4.2.1; en-us; Nexus 5 Build/Jop40d) Applewebkit/535.19 (KHTML, Gecko; Googleweblight) Chrome/38.0.1025.166 Mobile Safari/535.19” 66.249. 84–[22/nis/2020: 14: 05: 02 +0200] “Get /es/wp-conent/uploads/sites/3/2018/07/aziz-acharki-549137-unsplash-540×350.jpg http/ 1.0 “200 10566” https://neliosoftware.com/es/blog/imagenes-reguity-para-tu-blog/ “” Mozilla/5.0 (Linux; Android 4.2.1; en-us; Nexus 5 Build/Jop40d) Applewebkit/535.19 (Khtml, Gecko gibi; Googleweblight) Chrome/38.0.1025.166 Mobil Safari/535.19 “66.249.83.82 – – – – [ /Screenshot-of-unsplah-webite-768×520.png http/1.0 “200 399577” https://neliosoftware.com/blog/imagenes-6-tu-blog/ “” “” “Mozilla/5.0 (linux; Android 4.2.1; en-us; Nexus 5 Build/Jop40d) AppleWebk IT/535.19 (Khtml, Gecko gibi; GoogleWeblight) Chrome/38.0.1025.166 Mobil Safari/535.19 “… 188.79.17.218-[Nisan/2020: 14: 06: 14 +0200]” GET/ES/Blog/Problemas-Mas-Comumens-DE- WordPress/ http/1.0 “200 110741” https://www.google.com/ “” Mozilla/5.0 (Macintosh;
Intel Mac Mac OS X 10_12_6) Applewebkit/605.1.15 (Khtml, Gecko gibi Khtml)/12.1.2 Safari/605.1.15 “188.79.17.218 – – [Nisan/2020: 14: 06: 16 +0200]” Get/”Get/” ES/WP-Conent/Eklentiler/Nelio-Ab-Testing/Vars/Dist/Dist/JS/alternatif-yükleyici.js? Versiyonu = 52B0FF65C68AB39896D47D6FF673FD59 HTTP/1.0 “200 2763” https-1.0 “200 2763″ https- Mas-Comunes-de-Wordpress/”” Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebkit/605.1.15 (KHTML, Gecko gibi)/12.1.2 Safari/605.1.15 “188.79.17.218– [ 22/nis/2020: 14: 06: 16 +0200] “get /es/wp-cludes/css/dist/block-library/style.min.css?ver=5.4 http/1.0” 200 7627 “https:/ /neliosoftware.com/es/blog/problemas-mas-comunes-wordpress/ “” Mozilla/5.0 (Macintosh; intel mac OS X 10_12_6) Applewebkit/605.1.15 (Khtml, Gecko gibi) sürüm/12.1.2 Safari /605.1.15 “… Daha yakından bakalım: 66.249.83.82. Bu, isteği yapan cihazın IP’sidir.
22/Nis/2020: 14: 04: 59 +0200. Bu, talebin kesin tarihi ve saatidir.
Get/buz/blog/resimler-Geratuity-tu-blog/http/1.0. Ardından, ziyaretçilerin blogumuzdan (İspanyolca) (get) gönderileri istediklerini görüyoruz.
Mozilla/5.0 (Linux; Android … bunlar tarayıcı kullanıcılarıdır ve bize istekte bulunan cihazlar ve işletim sistemleri hakkında bazı bilgiler verir.
Sunucumuzun birinciden sonra aynı IP’den (66.249.83.82) nasıl birkaç istek aldığını unutmayın. Bu bir saldırı gibi görünebilir, ancak aslında değil: Web sayfaları genellikle bazı varlıklar (resimler, komut dosyaları, stiller) içerir ve sitenizdeki belirli web sayfalarına erişen ziyaretçiler her şeyi almak için bazı istekler yapacaksa çok normaldir. Dava, gerçekten olağanüstü bir talebimiz olduğunu doğrulayabiliriz. Aslında çok yüksek. Ve biliyoruz çünkü günlük dosyası normalden çok daha büyük. Olası açıklama, birkaç nedenden dolayı ziyaretlerin zirvesi olduğudur … ancak Google Analytics’e göre sorun bu değil. Yani farklı bir şey olur. Aşağıdaki gerçekleri tanımlamak için bizi tanımlamak için erişime daha ayrıntılı erişim: Aldığımız tüm taleplerin% 15’inden fazlası aynı IP’den gelir. Ve (Drum Roll) IP kendi web sunucumuz!
Bu noktada suçluyu tanımlamak nihayet kendi sunucumuzun CPU kullanımının bir zirvesini üretmek için çok fazla istekte bulunduğunu öğrendik. Ama neden? Bu neden oldu? İsteği kim yaptı? Bu cevaplanması daha zor bir soru. İlk olarak, günlüğümüzü tekrar görüyoruz, IP’ye dayalı filtre ve karşılaşılan sorunları açıklayabilecek kalıpları tanımlamaya çalışıyoruz: 35.214.244.124 – – 1.0 “301 -” https://neliosoftware.com/es “” php -quess/1.7-3470169 “35.214.244.124 – – [Nis/2020: 14: 06: 08 +0200]” get/es? … “” PHP-Requests/1.7-3470169 “35.214.244.124-[Nis/2020: 14: 06: 18 +0200]” GET/ES? – [22/Nis/2020: 14: 07: 21 +0200] “Get/es? 24 +0200] “Get/es? …” “PHP-RQUESS/1.7-3470169” … Ve bir tane bulduk: Tüm anormal isteklerin kullanıcı ajanı PHP-Requests/1.7-3470169. İlginç!
WordPress, istekleri tetiklemek için çeşitli işlevlere sahiptir: wp_remote_request.Bu işlevlerin kaynak koduna bakarsanız, temel olarak sınıfın WP_http adlı çeşitli yöntemlerini sardıklarını göreceksiniz.Bu sınıf ilginçtir, çünkü varsayılan olarak, ajanları “WordPress/Sürüm” olarak düzenlediği tüm talepler, bu yüzden belki de sorunlarımızla bir ilgisi vardır.Ama bu henüz değil.WordPress kaynak kodunu kontrol etmeye devam edersek, WP_http’in gerçekten bir istekte bulunmak için dahili olarak diğer WordPress sınıflarını kullandığını görüyoruz: istekler.Ve bir çocuk ilginç bir sınıftır: tanımının başında, onu 1.7-3470169 değerine sahip sürekli bir versiyon tanımladığını gördük.Ve biraz sonra, bu sabiti günlüğümüzde bulduğumuz ajanları oluşturmak için kullandı: PHP-Requests/1.7-3470169.
Muhteşem! Şimdi aldığımız tüm garip isteklerin WordPress sitemizden geldiğini doğruladık. Bu, suçlu bir eklenti olduğu anlamına gelebilir … ama hangisi? Bulmamız gereken fikri oldukça basit: Kullanıcı ajanını, istek sınıfını kullanan eklentinin adını içerecek şekilde değiştirirsek, eklentinin adını sunucumuzun günlük erişiminde göreceğiz. Ve bunu başarmak aslında oldukça kolay. Tek yaptığımız, aşağıdaki snippet’lerle ‘get_default_options isteklerini düzenlemektir: $ trace = debug_backtrace (); $ files = []; foreach ($ trace olarak $ log) {if (false! == Strpos ($ log [‘dosya’], ‘/wp-content/eklentiler/’) {$ files [] = $ log [‘file’]; }} if (boş ($ dosyalar)) {$ debug = ‘no-plugin’; } else {$ eklentileri = array_map (function ($ x) {return preg_replace (‘/.*/wp-concent/plugins/()/––++)/.*/’, ‘$ 1’, $ x) ;, $ dosyalar); $ eklentileri = array_unique ($ eklentiler); $ debug = improde (”, $ eklentiler); } $ Defaults [‘UserAgent’]. = “(Neliodebug {$ debug})”; Bakalım adım adım ne yaptığını görelim: Önce Debug_backtrace ile bir yığın yürütme alıyoruz. Bu, bugüne ulaşmak için çağrılan tüm işlevleri ortaya çıkaran geri dönüş üreten bir PHP işlevidir.

Yürütme yığınındaki her öğe için, çağrılan işlev, onu tanımlayan dosya ve satır, onu çağıran argüman vb. Gibi bilgilerimiz var. Bununla birlikte, odaklanmak istediğimiz şey, işlevinin tanımlandığı bir dosyadır: WP-Content/Eklentilerde varsa, bir eklentide belirtilen bir işlev olduğundan emin olarak biliyoruz.