WordPress Heartbeat API CPU’yu Neden Yükseltir?

Yönetim panelinde birden fazla editör çalışırken CPU kullanımı yükseliyor, PHP-FPM süreçleri doluyor veya admin-ajax.php istekleri erişim kayıtlarında öne çıkıyorsa Heartbeat API incelemeniz gereken bileşenlerden biridir. Ancak yalnızca CPU grafiğine bakarak Heartbeat’i suçlamak doğru değildir.

Heartbeat API, tarayıcı ile WordPress arasında düzenli aralıklarla küçük istekler gönderen iletişim mekanizmasıdır. Bu istekler oturum, otomatik taslak kaydı, yazı kilidi ve bazı eklentilerin canlı durum bilgileri için kullanılabilir. Her çağrı WordPress tarafından işlendiği için istek sayısı ve bu çağrıların tetiklediği eklenti kodu arttıkça sunucu yükü de büyüyebilir.

Bu içerik, WordPress Heartbeat API CPU kullanımı sorununu ölçme, nedenini ayırma ve en dar kapsamlı düzeltmeyi seçme adımlarını ele alıyor. Amaç Heartbeat’i gelişigüzel kapatmak değil, ihtiyaç duyulmayan çağrıyı azaltırken gerekli editör özelliklerini korumaktır.

Heartbeat API CPU kullanımını nasıl yükseltir?

Heartbeat API, WordPress’in tarayıcı tarafında düzenli aralıklarla çalışan iletişim mekanizmasıdır. Tarayıcı belirli bir aralıkta WordPress’e istek gönderir; WordPress de bu isteği işleyip gerekli yanıtı üretir. Yönetim panelinde bu istekler çoğunlukla /wp-admin/admin-ajax.php üzerinden yürür.

Bir Heartbeat isteği küçük görünse de sunucu tarafında yalnızca tek bir satır okunmaz. WordPress çekirdeği başlatılır, etkin eklentiler ve tema yüklenir, ilgili kancalar çalışır ve bazı durumlarda veritabanı sorguları yapılır. Bu işlemler kısa sürse bile aynı anda çok sayıda tarayıcı isteği oluştuğunda toplam PHP çalışma süresi büyür.

Varsayılan aralık kullanılan bağlama göre değişebilir. Yönetim panelinde daha sık, ön yüzde ise daha seyrek çağrı görülmesi normaldir. Editör ekranı otomatik kaydetme veya yazı kilidi gibi işlevler nedeniyle farklı davranabilir. Bu yüzden yalnızca Heartbeat’in kaç saniyede bir çalıştığına değil, her çağrının hangi kodu tetiklediğine de bakmanız gerekir.

Asıl yük çoğu zaman eklenti işleyicisindedir

Heartbeat isteği bir taşıma kanalıdır. Bir eklenti bu kanala ürün stok kontrolü, canlı bildirim, oturum kontrolü, analiz veya özel bir AJAX işlemi ekleyebilir. İşleyici her çağrıda ağır bir sorgu çalıştırıyor, dış bir servise bağlanıyor ya da büyük bir veri kümesini işliyorsa CPU ve veritabanı kullanımı artar.

Örneğin yalnızca editör açıkken artan yük, otomatik taslak ve yazı kilidi işlemleriyle ilgili olabilir. Çok sayıda yönetici oturumu açıkken artan yük ise her oturumun kendi zamanlayıcısıyla yaptığı çağrıların birleşiminden kaynaklanabilir. WooCommerce kullanılan sitelerde yönetim paneline eklenen sipariş, stok veya bildirim özellikleri de Heartbeat çağrılarını ağırlaştırabilir.

Önce Heartbeat kaynaklı yükü nasıl ölçersiniz?

İlk adım, CPU yükselişi ile Heartbeat çağrısı arasındaki zaman ilişkisini doğrulamaktır. Ani yoğunluk yalnızca Heartbeat’e bağlanırsa yanlış eklentiyi devre dışı bırakabilir veya editör işlevlerini gereksiz yere bozabilirsiniz.

Sunucu metrikleriyle zaman aralığını belirleyin

CPU, PHP-FPM çalışan süreçleri, yük ortalaması ve veritabanı kullanımını aynı zaman aralığında inceleyin. Yönetim panelinde editör açıldığında mı, belirli sayıda kullanıcı giriş yaptığında mı, yoksa arka plan görevleri çalışırken mi artış olduğunu not edin.

PHP-FPM web işçileri ile CLI üzerinden çalışan cron veya kuyruk işçilerini birbirinden ayırın. Bir WP-Cron görevi veya CLI kuyruğu doğrudan HTTP isteği yapmıyorsa PHP-FPM web işçisi tüketmez; bu durumda CPU artışını otomatik olarak Heartbeat’e bağlamayın. Aynı saatlerde çalışan bir cron görevi, veritabanı sorguları veya yedekleme işlemi ayrı bir kaynak olabilir.

Tarayıcı ağ kayıtlarında isteği doğrulayın

Yönetici hesabınızla sorun görülen ekrana girin. Tarayıcı geliştirici araçlarında Network veya Ağ sekmesini açın ve admin-ajax.php isteklerini filtreleyin. İsteklerin sıklığını, yanıt süresini ve yanıt boyutunu kaydedin. Editör kapatıldığında isteklerin durup durmadığını da kontrol edin.

İstek gövdesindeki action=heartbeat değerini görmek, çağrının Heartbeat akışıyla ilişkili olduğuna dair güçlü bir işarettir. Bu kontrol CPU miktarını tek başına ölçmez; hangi ekranın hangi sıklıkta istek oluşturduğunu anlamanızı sağlar.

Erişim kayıtlarında toplam hacmi karşılaştırın

Web sunucusu erişim kayıtlarında admin-ajax.php isteklerini zaman aralığına göre sayın. Mümkünse yönetim paneli kullanıcı sayısı, yanıt durumu ve istek süresiyle birlikte inceleyin. Aynı URL’ye gelen her istek Heartbeat değildir; bu nedenle kayıtları yalnızca URL yoluna göre yorumlamayın.

Sunucunuzda istek başına işlem süresini görebilen bir gözlemleme aracı varsa Heartbeat çağrılarındaki yavaşlamayı karşılaştırın. Bir isteğin yavaş olması ile çok sayıda kısa isteğin toplamda yük oluşturması farklı sorunlardır ve düzeltmeleri de farklıdır.

Uygulama katmanında ağır işleyiciyi arayın

Geçici olarak Query Monitor gibi bir geliştirme aracından, staging ortamından veya sunucu tarafı profil bilgisinden yararlanabilirsiniz. Amaç, Heartbeat sırasında çalışan sorgu, kanca ve eklentiyi bulmaktır. Üretim sitesinde profil aracını kalıcı olarak açık bırakmayın; önce test veya staging ortamında deneyin.

Bir eklentiyi pasif ederek yükün azalıp azalmadığını kontrol edecekseniz önce yedek alın, değişikliği düşük trafik saatinde yapın ve geri alma adımını belirleyin. WooCommerce veya güvenlik eklentileri gibi kritik bileşenleri rastgele kapatmak yerine staging üzerinde karşılaştırma yapın.

Belirtilere göre nedeni nasıl ayırırsınız?

CPU grafiğinin ne zaman yükseldiği, hangi düzeltmenin daha güvenli olacağını gösterir. Aynı işlem hem yönetim panelinde hem de ön yüzde görülüyorsa kapsamı geniş bir ayar yapmak yerine iki bağlamı ayrı test edin.

Yalnızca editör açıkken CPU artıyorsa

Otomatik taslak kaydı, yazı kilidi ve editörle çalışan eklentiler ilk adaylardır. Aynı yazıyı iki tarayıcıda açıp yazı kilidi davranışını, taslak kaydını ve admin-ajax.php sıklığını karşılaştırın. Yük yalnızca belirli bir içerik türünde oluşuyorsa o içerik türüne bağlı eklenti veya özel kodu inceleyin.

Bu durumda tüm Heartbeat trafiğini kapatmak yerine aralığı artırmak veya ağır işleyiciyi düzeltmek daha dar müdahaledir. Editörün otomatik kaydetme aralığını ayrıca değiştirmek, Heartbeat sorununu çözmeyebilir; iki mekanizmanın aynı isteği kullanıp kullanmadığını doğrulayın.

Yönetim panelinde birçok kullanıcı varken artıyorsa

Her açık sekme düzenli istek gönderir. Kullanıcı sayısı ve sekme sayısı arttıkça kısa işlemler bile PHP-FPM havuzunu doldurabilir. Bu durumda PHP-FPM ayarlarını hemen büyütmek yalnızca bekleyen işleri artırabilir; önce çağrı sıklığını ve çağrı başına süreyi ölçün.

Sunucu kaynaklarını site trafiğiyle birlikte değerlendirmek için WordPress Blog, WooCommerce ve SaaS İçin Kaç CPU, Ne Kadar RAM? başlıklı çalışmadaki kapasite yaklaşımından yararlanabilirsiniz. Bu bağlantı Heartbeat için hazır bir CPU değeri vermez; kaynak planlamasını trafik, eşzamanlı kullanıcı ve iş yüküyle birlikte düşünmenize yardımcı olur.

Ön yüzde de çağrılar görünüyorsa

Ön yüzdeki Heartbeat çağrıları canlı bildirim, sepet veya özel tema özellikleri tarafından kullanılabilir. Bu özelliklerden hiçbiri gerekmiyorsa ön yüz Heartbeat’ini kaldırmak, yönetim panelindeki otomatik kaydetme ve yazı kilidi davranışını etkilemeden daha dar bir çözüm olabilir.

Ön yüzde Heartbeat kullanan bir eklenti varsa kaldırma işleminden önce işlevin gerçekten gereksiz olduğunu doğrulayın. Özellikle canlı sepet veya kullanıcı oturumu gibi özellikler sessizce bozulabilir; tarayıcı geliştirici araçlarında hata ve eksik yanıt kontrolü yapın.

CPU değil veritabanı bekleme süresi artıyorsa

Heartbeat çağrıları çok sayıda sorgu oluşturuyorsa CPU grafiği tek belirti olmayabilir. Veritabanı bağlantı süresi, disk beklemesi ve yavaş sorgular da yükselir. Bu durumda yalnızca PHP-FPM sayısını artırmak sorunu çözmez.

Object cache kullanılmayan veya yanlış yapılandırılan sitelerde aynı verinin tekrar tekrar sorgulanması ek yük doğurabilir. WordPress’te Redis/Memcached Object Cache Kurulumu hakkında bilgi edinirken önbelleğin sorguyu gerçekten azaltıp azaltmadığını ve veri tutarlılığı gereksinimlerini kontrol edin. Önbellek kurulumu Heartbeat işleyicisindeki hatalı sorguyu düzeltmenin yerine geçmez.

En dar kapsamlı düzeltmeyi nasıl seçersiniz?

Ölçüm sonucu Heartbeat kaynaklı yükü doğruladıktan sonra üç müdahale düzeyi vardır: çağrı aralığını artırmak, gereksiz bağlamdaki Heartbeat’i kaldırmak ve ağır işleyiciyi düzeltmek. İlk seçenek en kolay geri alınandır; üçüncü seçenek ise kök nedene en doğrudan müdahaledir.

Yönetim panelinde aralığı artırın

Editör işlevleri korunmalı, fakat saniyeler içinde güncellenmesi gerekmeyen bir panelde aralık artırılabilir. Bunu önce staging ortamında veya sınırlı bir yönetici grubuyla test edin. Temanızın veya eklentinizin güncelleme yöntemi üzerine doğrudan kod eklemek yerine mümkünse sürüm kontrolü yapılan özel bir eklenti ya da mu-plugin kullanın.

Aşağıdaki örnek, yönetim bağlamında Heartbeat ayarındaki aralığı 60 saniyeye çıkarmayı gösterir. Bu değer örnek bir başlangıçtır; otomatik kaydetme ve yazı kilidi gereksiniminize göre doğrulama yapmadan üretimde kullanmayın.

<?php
add_filter( 'heartbeat_settings', function ( $settings ) {
    if ( is_admin() ) {
        $settings['interval'] = 60;
    }

    return $settings;
} );

Ön koşul, kodun geçerli PHP sözdizimiyle yüklenebildiği ve değişikliği geri alabileceğiniz bir dağıtım yöntemine sahip olmanızdır. Dosyayı değiştirmeden önce mevcut dosyanın ve site yedeğinin geri dönüş için kullanılabilir olduğundan emin olun.

Değişiklikten sonra editör açın, yazıyı taslak olarak kaydedin, aynı yazıyı ikinci bir oturumda açarak kilit davranışını kontrol edin. Tarayıcı ağ kayıtlarında çağrı aralığını, sunucu tarafında ise PHP-FPM yoğunluğunu yeniden ölçün. Sorun artarsa kodu kaldırarak önceki duruma dönün.

Ön yüzde gereksizse Heartbeat’i kaldırın

Ön yüzde Heartbeat’e ihtiyaç olmadığı doğrulanırsa yalnızca ön yüz betiğini kaldırmayı düşünebilirsiniz. Aşağıdaki örnek, ön yüz varlıkları yüklenirken Heartbeat betiğini kaldırır; yönetim panelini hedeflemez.

<?php
add_action( 'wp_enqueue_scripts', function () {
    wp_deregister_script( 'heartbeat' );
}, 100 );

Bu kodu kullanmadan önce tema ve eklentilerinizin ön yüzde Heartbeat’e bağlı olup olmadığını kontrol edin. Test sırasında canlı bildirim, sepet, kullanıcı oturumu ve özel AJAX özelliklerini ayrı ayrı deneyin. Bir özellik bozulursa kodu geri alın; ilgili özelliği koruyup yalnızca gereksiz işleyiciyi düzeltmek daha doğru olabilir.

Ağır eklenti işleyicisini düzeltin

Profil sonucunda belirli bir eklentinin Heartbeat çağrısında pahalı sorgu çalıştırdığı görülüyorsa sıklığı değiştirmek yalnızca belirtileri azaltır. Eklentiyi güncelleyin, desteklenen ayarlarını inceleyin veya geliştiriciden Heartbeat dışı bir yöntem isteyin. Özel kod varsa sorguyu yalnızca gerekli kullanıcı, ekran veya veri değiştiğinde çalışacak şekilde daraltın.

Bir işin her Heartbeat çağrısında dış API’ye bağlanması özellikle kırılgandır. Ağ gecikmesi PHP-FPM işçisini bekletebilir ve aynı anda gelen isteklerin kuyruğunu büyütebilir. Bu tür işleri önbelleğe almak, zamanlanmış görevle ayırmak veya yalnızca kullanıcı açıkça istediğinde çalıştırmak daha sağlıklı olabilir. Bu değişiklikler uygulamanın davranışını etkileyebileceği için önce staging ve geri dönüş planı gerekir.

Değişiklik sonrası hangi sonuçları doğrulamalısınız?

Başarılı bir düzeltme yalnızca CPU grafiğinin düşmesi değildir. Aynı anda istek hacmi, PHP-FPM bekleme durumu, veritabanı gecikmesi ve WordPress işlevleri birlikte kontrol edilmelidir.

• Tarayıcı Network sekmesinde admin-ajax.php ve action=heartbeat çağrılarının beklenen sıklığa indiğini doğrulayın.
• CPU, PHP-FPM aktif ve bekleyen işçi sayısı ile yanıt sürelerini değişiklik öncesi aynı zaman aralığıyla karşılaştırın.
• Editörde otomatik taslak kaydını, yazı kilidini ve birden fazla oturumdaki düzenleme davranışını test edin.
• Ön yüzde Heartbeat kaldırıldıysa canlı bildirim, sepet ve oturumla ilgili özellikleri kontrol edin.
• Erişim kayıtlarında hata durumlarının veya aşırı uzun yanıt sürelerinin artmadığından emin olun.

Site Sağlığı raporu WordPress yapılandırması, güncelleme ve barındırma ortamına ilişkin ek uyarılar sunabilir. WordPress Site Sağlığı Raporu Nasıl Okunur? başlıklı içerikteki yaklaşımı kullanarak bu raporu Heartbeat ölçümlerinin yerine değil, tamamlayıcısı olarak değerlendirin.

Heartbeat’i tamamen kapatmak ne zaman mantıklıdır?

Heartbeat’i tümüyle kapatmak ancak kullandığınız ekran ve eklentiler bu iletişime ihtiyaç duymuyorsa düşünülebilir. Tek yazarlı, yalnızca statik içerik yöneten ve ön yüzde canlı özellik kullanmayan bir site daha sınırlı bir kullanım alanına sahip olabilir. Buna rağmen yönetim panelinde otomatik kaydetme ve yazı kilidi kaybının operasyonel etkisini hesaba katın.

Çok yazarlı sitelerde veya WooCommerce yönetim ekranlarında tamamen kapatma daha risklidir. Editör çakışmaları, taslak kaybı ya da eklentiye bağlı yönetim işlevlerinin bozulması CPU tasarrufundan daha maliyetli olabilir. Önce aralığı artırmak, belirli ekranı veya ön yüz bağlamını hedeflemek ve ağır işleyiciyi düzeltmek daha kontrollü seçeneklerdir.

Sık Sorulan Sorular

Heartbeat API ile WP-Cron aynı şey midir?

Hayır. Heartbeat, tarayıcı ile WordPress arasındaki düzenli HTTP iletişimidir. WP-Cron ise zamanlanmış görevlerin çalıştırılması için kullanılan mekanizmadır. Bir eklenti Heartbeat isteği sırasında cron benzeri iş yapabilir; bu iki sistemin aynı olduğu anlamına gelmez.

Heartbeat CPU yerine RAM kullanımını da artırır mı?

Evet, dolaylı olarak artırabilir. Her PHP isteği bellek kullanır ve aynı anda daha fazla istek oluştuğunda PHP-FPM havuzundaki toplam bellek tüketimi yükselebilir. Etkiyi doğrulamak için CPU ile birlikte aktif PHP-FPM işçilerini ve bellek kullanımını izleyin.

Önbellek eklentisi Heartbeat sorununu çözer mi?

Sayfa önbelleği genellikle oturum gerektiren admin-ajax.php akışını doğrudan çözmez. Object cache bazı tekrar eden veritabanı sorgularını hafifletebilir; fakat hatalı veya gereksiz Heartbeat işleyicisini ortadan kaldırmaz.

Heartbeat aralığını 60 saniyeye çıkarmak otomatik kaydetmeyi geciktirir mi?

Heartbeat üzerinden çalışan işlemler daha seyrek tetiklenebilir; bu nedenle gecikme olabilir. Kesin etki, kullandığınız WordPress sürümüne, editöre ve eklentilere bağlıdır. Değişikliği uygulamadan önce taslak kaydı ve yazı kilidini gerçek ekranlarda test edin.

Uygulanabilir kontrol listesi

1. CPU yükselişinin zamanını, kullanıcı sayısını ve açık yönetim ekranlarını not edin.
2. Tarayıcıda admin-ajax.php çağrılarını ve action=heartbeat değerini doğrulayın.
3. Erişim kayıtlarını, PHP-FPM metriklerini ve veritabanı gecikmesini aynı zaman aralığında karşılaştırın.
4. Heartbeat işleyicisini ağırlaştıran eklenti veya özel kodu staging ortamında ayırın.
5. Önce yönetim aralığını artırma veya yalnızca gereksiz ön yüz çağrılarını kaldırma gibi dar müdahaleyi test edin.
6. Otomatik taslak, yazı kilidi, canlı özellikler ve hata kayıtlarını değişiklik sonrası yeniden kontrol edin.
7. CPU düşmüyorsa Heartbeat dışındaki cron, kuyruk, sorgu ve trafik kaynaklarını inceleyin.

Bir sonraki adımınız, sorun yaşanan saatten kısa bir erişim kaydı ve tarayıcı ağ çıktısı almaktır. Bu iki veri, Heartbeat çağrılarının gerçekten yoğunluğu oluşturup oluşturmadığını ve hangi çözümün en az yan etkiyle uygulanacağını belirlemenizi sağlar.