Beş aylık izleme: Common Crawl indeks sorgularının üçte biri yanıt alamıyor

Beş aylık günlük izleme, Common Crawl indeksinin kendisine gönderilen sorguların yaklaşık üçte birini yanıtlayamadığını, başarısızlıkların UTC sabahının erken saatlerinde kümelenmiş olduğunu gösteriyor. Veriler, 15 Mayıs'tan beri küçük bir Cloudflare Worker çalıştıran ve günde bir kez indekse, kişisel bir siteden alınan yaklaşık bir düzine URL'nin güncel crawlede yer alıp almadığını soran bir geliştiricinin dev.to'daki yazısından geliyor.

Rakamlar ne gösteriyor

Gönderiye göre kontrol kasıtlı olarak basit: crawl koleksiyonlarının listesini çek, URL başına bir CDX sorgusu çalıştır ve yanıtı içeren bir satır sakla. 173 anlık görüntü ve 1.889 tekil sorgu boyunca 605'i — yüzde 32 — hiç yanıt almadı. Bildirilen dağılım şöyle: 344 HTTP 503 yanıtı, 103 HTTP 504, 80 HTTP 521 (origin'e ulaşılamadığında Cloudflare'in döndürdüğü durum kodu), 52'si worker'ın kendi zaman aşımı tarafından kesilen istek, ayrıca 18 HTTP 502, yedi 500 ve tek bir 520. 173 anlık görüntünün 11'inde her sorgu başarısız oldu.

Başarısızlıklar 04:00 UTC civarında kümeleniyor

Zamanlanmış görev 04:00 UTC'de tetikleniyor ve veriler bu çizgiye göre ayrışıyor. 03:00 ile 06:00 UTC arasında yapılan sorgular 1.339'da 491 kez, yaklaşık yüzde 37 oranında başarısız oldu. Diğer saatlerdeki sorgular 550'de 114 kez, kabaca yüzde 21 oranında başarısız oldu.

Yazar bu ayrımda dikkatli: saat dışı anlık görüntülerin çoğu, yalnızca sabah çalışması zaten başarısız olduktan sonra, servisin toparlanıyor olabileceği bir anda başlatılan manuel yeniden çalıştırmalardı. Bu yanlılığa rağmen eğilim beş ay boyunca korunmuş durumda ve Ekim, 132 sorgudan 79'unun başarısız olduğu şekilde şimdiye kadarki en kötü ay oldu.

Yeniden denemeler yardımcı oldu, ama kesintilere değil

10 ve 11 Ekim'de görev URL sorgularına bile ulaşamadı. Koleksiyon listesi isteği HTTP 521 döndürdü ve Ağustos'tan beri yeniden denemeleri olan URL sorgularının aksine bu çağrının yeniden denemesi yoktu; bu yüzden tüm aşama başarısız oldu ve hiçbir şey yazılmadı. Geliştirici 10 ve 20 saniyelik beklemeyle üç deneme ekledi. 12 Ekim'de koleksiyon listesi geldi; ardından dokuz URL sorgusunun tamamı 521 döndürdü.

Aynı kodun aynı URL'lere karşı öğleden sonra yapılan yeniden çalıştırmaları çok daha iyi sonuç verdi: 10 Ekim'de 12 sorgunun 12'si, 11 Ekim'de 12'de 10'u yanıtlandı. Gönderi yazılırken, yaklaşık 06:10 UTC'de, düz bir curl isteği koleksiyon listesi için 200, bir URL sorgusu için 504 aldı.

Gönderideki çıkarım, birkaç saniye arayla yapılan yeniden denemelerin tek bir isteğin düşmesi durumunda yardımcı olduğu, ama saatlerce erişilemeyen bir indeks için hiçbir şey yapmadığı yönünde. Planlanan sonraki değişiklik, saniyeler yerine saatler sonra ikinci bir deneme.

Hata, yokluk ile aynı şey değildir

İkinci ders, başarısızlıkların nasıl kaydedildiğiyle ilgili. Başarısız bir sorgu hata olarak saklanır, asla olumsuz sonuç olarak değil; dahil edilme oranı yalnızca gerçekten yanıt alan URL'ler üzerinden hesaplanır ve çok az URL yanıt verirse oran, bir sayı göstermek yerine boş kalır. 11 Ekim'de bu disiplin, "yanıt veren 10 URL'den 7'si crawl içinde" demek ile "12 URL'nin tamamının yalnızca 7'si dahil" iması arasındaki farktı. Doğru olan yalnızca ilk ifade. Hatalar olumsuz sonuca katılsaydı, indeks sadece erişilemezken Ekim, sitenin Common Crawl'dan düştüğü izlenimini verirdi.

Neden önemli

Common Crawl, web araştırmaları ve下游 araçlar için temel bir veri kümesi ve indeksi çoğu zaman yavaş ama güvenilir bir genel uç nokta olarak görülüyor. Bu kanıt, bir düzine kadar URL'yi yoklayan tek bir izleyiciden geliyor ve yazar verilerdeki seçim etkilerini açıkça belirtiyor; ancak başarısızlık oranı beş aydır tutarlı ve Ekim'de en kötü düzeyinde. İndeksi zamanlamış olarak yoklayan herkes, gönderinin kapanış tavsiyesini izlemeli: sorguların ne söylediğini yorumlamadan önce kaçının gerçekten yanıt döndürdüğünü kontrol edin, yeniden denemeleri saniyeler yerine saatler cinsinden planlayın ve eksik bir yanıtı kesinlikle olumsuz sonuçtan ayrı tutun. Aksi halde bir erişilebilirlik sorunu sessizce veri hakkında yanlış bir sonuca dönüşür.