Worker limiti ve CPU limiti arasındaki farkı öğrenin; WordPress sitelerde kaynak aşımı, yavaşlama ve doğru hosting seçimi için pratik ipuçları alın.
Bir web sitesinde yavaşlama, 503 hatası veya panelde kaynak aşımı uyarısı görüldüğünde çoğu kullanıcı sorunun doğrudan işlemci gücünden kaynaklandığını düşünür. Oysa performans problemlerinde iki farklı sınır sıkça karşımıza çıkar: worker limiti ve CPU limiti. Bu iki kavram birbirine yakın görünse de farklı kaynakları yönetir, farklı belirtiler üretir ve doğru çözüm yolu da buna göre değişir. Özellikle paylaşımlı hosting paketlerinde bu ayrımı bilmek, gereksiz paket yükseltmelerini veya yanlış optimizasyon adımlarını önler.
Worker limiti, aynı anda işlenebilen dinamik istek sayısını ifade eder. Bir ziyaretçi WordPress sayfası açtığında, yönetim paneline giriş yaptığında, WooCommerce sepetini güncellediğinde veya bir form gönderdiğinde sunucu bu isteği işlemek için bir worker kullanabilir. Worker, isteğin tamamlanmasına kadar meşgul kalır.
Basit bir örnekle; sitenizde 10 worker varsa ve aynı anda 10 dinamik işlem çalışıyorsa, 11. istek sıraya alınabilir veya yapılandırmaya göre hata üretebilir. Bu durum CPU’nun tamamen dolu olduğu anlamına gelmez. İşlemler uzun sürdüğü için worker havuzu tükenmiş olabilir.
Worker limiti genellikle yavaş çalışan PHP işlemleri, yoğun yönetim paneli kullanımı, ağır eklentiler, dış API beklemeleri veya önbelleğe alınmayan dinamik sayfalar nedeniyle dolar. Örneğin ödeme adımında üçüncü taraf servis yanıtı gecikiyorsa, ilgili worker bu süre boyunca boşta bekliyor gibi görünse de yeni isteklere hizmet veremez.
Bu nedenle worker sorunlarında asıl hedef, aynı anda daha fazla işlem açmaktan önce mevcut işlemlerin daha kısa sürede tamamlanmasını sağlamaktır.
CPU limiti, sitenizin sunucuda kullanabileceği işlemci gücünü sınırlar. PHP kodlarının çalışması, veritabanı sorgularının hazırlanması, görsel işleme, sık çalışan cron görevleri ve yoğun eklenti işlemleri CPU tüketimini artırabilir. CPU limiti aşıldığında işlemler yavaşlayabilir, bekleme süreleri uzayabilir veya hesap geçici olarak kısıtlanabilir.
Burada kritik fark şudur: CPU limiti işlemci gücüyle ilgilidir; worker limiti ise aynı anda kaç dinamik isteğin işlenebileceğiyle ilgilidir. Yani bir sitede CPU kullanımı düşükken worker limiti dolabilir. Tersi şekilde, worker sayısı yeterli olsa bile kötü optimize edilmiş bir sorgu CPU’yu zorlayabilir.
İki limit arasındaki farkı doğru okumak için belirtilere bakmak gerekir. Worker limiti dolduğunda genellikle ani trafik artışlarında sayfalar bekler, bazı kullanıcılar 503 benzeri hatalar görür veya yönetim paneli geç yanıt verir. CPU limiti aşıldığında ise genel yavaşlama daha belirgin olur; sayfa üretim süreleri artar, cron görevleri siteyi yorabilir ve eklenti işlemleri gecikebilir.
Worker limiti ve CPU limiti farkı özellikle e-ticaret, üyelik sistemi ve rezervasyon gibi dinamik sitelerde daha önemlidir. Çünkü bu yapılarda her ziyaretçi yalnızca statik bir sayfa görüntülemez; sepete ekleme, filtreleme, oturum yönetimi ve ödeme gibi sunucu tarafında işlem gerektiren adımlar devreye girer.
Her performans sorununda paketi yükseltmek doğru ilk adım değildir. Önce sorunun kaynağına bakılmalıdır. Eğer site az ziyaretçide bile yavaşlıyor, özellikle belirli eklenti işlemlerinde işlemci kullanımı yükseliyorsa CPU tarafında optimizasyon veya daha güçlü bir sunucu gerekebilir. Eğer trafik dalgalanmalarında istekler sıraya giriyor, PHP işlemleri uzun sürüyor ve hata kayıtlarında eş zamanlı işlem sınırı görülüyorsa worker limiti daha kritik hale gelir.
Kurumsal sitelerde çoğu zaman önbellekleme worker ihtiyacını ciddi biçimde azaltır. Ancak üyelik panelleri, sepet ve ödeme sayfaları gibi kişiye özel alanlarda önbellek sınırlı çalışır. Bu nedenle dinamik süreçleri fazla olan projelerde sadece sayfa önbelleği yeterli görülmemelidir.
Yaygın hatalardan biri, worker limiti dolan bir sitede yalnızca CPU gücünü artırmaktır. İşlemler hâlâ uzun sürüyorsa ziyaretçiler yine bekleyebilir. Diğer hata ise CPU tüketimi yüksek olan bir sitede worker sayısını artırmaktır. Bu durumda aynı anda daha fazla ağır işlem çalışacağı için sunucu daha hızlı yorulabilir.
Doğru karar için erişim logları, hata kayıtları, PHP işlem süreleri, veritabanı sorgu yükü ve cron zamanlamaları birlikte değerlendirilmelidir. Tek bir panel metriğine bakarak karar vermek yanıltıcı olabilir.
WordPress kullanıyorsanız önce en çok kaynak tüketen alanları sadeleştirin. Gereksiz eklentileri devre dışı bırakın, veritabanı sorgusu yoğun sayfaları belirleyin ve tema tarafında ağır çalışan fonksiyonları kontrol edin. Yönetim panelinde yavaşlık yalnızca belirli bir eklenti ekranında yaşanıyorsa sorun genel sunucu kapasitesinden çok o eklentinin çalışma biçimiyle ilgili olabilir.
Önbellek yapılandırması da dikkatli ele alınmalıdır. Statik sayfalar, blog içerikleri ve kurumsal hizmet sayfaları önbelleğe alınabilir. Sepet, ödeme, kullanıcı hesabı ve form gönderim alanları ise yanlış önbellek ayarıyla hatalı çalışabilir. Bu ayrımı yapmak, hem kullanıcı deneyimini korur hem de hosting kaynaklarının daha verimli kullanılmasını sağlar.
Sağlıklı bir değerlendirme için yalnızca anlık CPU yüzdesine bakmak yeterli değildir. Ortalama yanıt süresi, en yavaş PHP istekleri, eş zamanlı bağlantı sayısı, veritabanı bekleme süreleri ve 5xx hata oranı birlikte izlenmelidir. Trafik saatlerine göre kaynak kullanımı değişiyorsa, kampanya ve reklam dönemlerinde ayrı kapasite planı yapılmalıdır.
Eğer sitenizde düzenli olarak kısa süreli zirveler yaşanıyorsa worker sayısı kullanıcı deneyimini doğrudan etkileyebilir. Buna karşılık gün boyu yüksek işlemci tüketimi varsa kod, eklenti, veritabanı veya paket kapasitesi yeniden değerlendirilmelidir.
Kapasite planı yaparken ziyaretçi sayısından çok ziyaretçilerin ne yaptığına odaklanmak gerekir. Sadece içerik okunan bir site ile aynı anda ürün filtrelenen, sepete ekleme yapılan ve ödeme alınan bir sitenin kaynak ihtiyacı aynı değildir. Bu nedenle teklif veya paket seçimi yapılırken sayfa görüntüleme, dinamik işlem oranı, yönetim paneli kullanımı ve kampanya trafiği birlikte konuşulmalıdır.
Teknik ekipten ya da sağlayıcıdan worker kullanımı, CPU tüketimi ve yavaş istek raporlarını istemek karar sürecini netleştirir. Raporlarda belirli sayfalar veya eklentiler öne çıkıyorsa önce optimizasyon yapılmalı; kaynaklar gerçekten yetmiyorsa daha uygun bir paket veya sunucu mimarisi tercih edilmelidir.