Bekleyen İş Her Zaman Hata Değildir
WooCommerce ve eklentileri bazı işleri ziyaretçinin beklediği sayfa isteğinden ayrı yürütebilir. Action Scheduler bu tür arka plan görevlerinin kuyrukta izlenmesini sağlar. Gelecek zaman için bekleyen bir görev ile çalışması gerektiği halde gecikmiş bir görev aynı anlama gelmez.
Örneğin yarın gönderilecek bir hatırlatma bugün beklemede olabilir. Buna karşılık dün başlaması gereken ürün aktarımının hâlâ beklemesi incelenmelidir. İlk değerlendirmede görev adı, planlanan zaman, mevcut durum ve son günlük kaydı okunur. Sadece bekleyen görevlerin toplam sayısını görmek, mağazanın sağlığı hakkında kesin bir sonuç vermez.
Zamanlayıcının Çalışma Koşulları
WordPress'in WP-Cron sistemi, zamanlanmış işleri değerlendirmek için sayfa yüklenmelerinden yararlanır. Bu nedenle planlanan saat, görevin o saniyede kesinlikle çalışacağı anlamına gelmez. Sunucuda ayrı bir zamanlayıcı kullanılıyorsa onun çalışma kayıtları da değerlendirmeye katılır.
Kurgusal bir mağazada gece ziyaretçi azaldığında aktarımın geciktiğini düşünün. Önce gecikmenin günün belirli saatlerinde mi, her zaman mı oluştuğu karşılaştırılır. Sorunu yalnızca mağazayı tarayıcıda yenileyerek geçici olarak gidermek kalıcı açıklama sağlamaz. Hangi mekanizmanın görevleri başlattığı ve başarısız denemelerin nerede kaydedildiği netleşmelidir.
Görev Çalışıyor ama Tamamlanmıyor
Zamanlayıcının görevi başlatması, görevin başarıyla biteceği anlamına gelmez. Dış API yanıtı, sunucu kaynak sınırı veya eklenti hatası işin sonucunu etkileyebilir. Action Scheduler günlükleri bu ayrımı incelemek için başlangıç noktasıdır; gerektiğinde ilgili eklentinin kendi hata kaydıyla birlikte okunur.
Örneğin katalog aktarımında ilk ürün grubu tamamlanıp ikinci grup hata veriyorsa bütün dosyanın hiç işlenmediği varsayılmaz. Son başarılı kayıt ve ilk başarısız kayıt belirlenir. Bu iki kayıt arasındaki ürün verisi veya uzak servis yanıtı, sürekli büyüyen kuyruktan daha açıklayıcı olabilir.
Tekrar Çalıştırmadan Önce
Bir görevin yeniden yürütülmesinin dış dünyadaki etkisi bilinmelidir. Görev e-posta gönderebilir, stok aktarabilir veya bir ödeme eklentisinin işlemini başlatabilir. Aynı görevi art arda çalıştırmanın zararsız olduğu varsayılmaz.
Örnek olarak tamamlanmış görünen bir sipariş bildirimi düşünün. Günlükte hata olsa bile e-posta sağlayıcısı mesajı kabul etmiş olabilir. Yeniden denemeden önce dış sistemdeki sonuç kontrol edilir. Tekrar çalıştırma kararı görev türüne göre verilir; bütün başarısız işleri topluca silmek veya çalıştırmak sorunun kanıtlarını kaybettirebilir. Kuyruk müdahalesi, işlemin ne yaptığı açıklığa kavuşturulduktan sonra planlanır.
Kalıcı İyileşme Nasıl Anlaşılır?
İyileşme değerlendirmesinde en eski gecikmiş işin yaşı, yeni görevlerin tamamlanma davranışı ve aynı hata nedeninin tekrar edip etmediği izlenir. Kuyruk sayısının bir anlığına düşmesi tek başına yeterli değildir; yeni siparişler geldikçe sistemin sürdürülebilir biçimde ilerlemesi gerekir.
Destek kaydında müşteri bilgileri yerine görev kimliği, ilgili eklenti, beklenen çalışma zamanı ve temizlenmiş hata mesajı bulunabilir. Birkaç farklı görev türü aynı anda gecikiyorsa ortak zamanlayıcı veya sunucu koşulları araştırılır. Yalnızca tek entegrasyon etkileniyorsa inceleme o görevin bağımlılıklarına daraltılır. Böylece gereksiz genel ayar değişikliklerinden kaçınılır.
Bu Yazıdaki Terimler 1 Kavram
Kısa açıklamaları burada okuyabilir, ayrıntılar için sözlüğe geçebilirsiniz.
- API
- API (Application Programming Interface), farklı yazılımların birbirleriyle veri alışverişi yapmasını sağlayan bağlantı yöntemidir.
Bu Konuda Nasıl Destek Oluyoruz?
AdPix’in bu alandaki hizmet kapsamını ve çalışma sürecini inceleyin.
WooCommerce