- Crawl Budget Management For Large Sites | Google Search Central | Documentation | Google for Developers
- Learn what crawl budget is and how you can optimize Google's crawling of large and frequently updated websites.
AI tarafından çevrilmiş metin.
durumis AI tarafından özetlenen yazı
- Google arama sürünümü bütçe verimliliğini artırmak için web sayfası aktarım hızını iyileştirme ve Cloud Run tabanlı Yönlendirme Servisi uygulamaya koyduk.
- robots.txt, favicon.ico gibi statik dosyalar ve yönlendirme mantığını Cloud Run'a taşıyarak, mevcut GKE Autopilot'a kıyasla yanıt süresini 200 ms'den 20 ms'ye düşürdük.
- Cloud Run'ı dünyanın dört bir yanındaki farklı bölgelerde dağıtarak, kullanıcı konumuna daha yakın sunuculardan hizmet sunarak hız artışı ve maliyet tasarrufu sağladık.
Tüm içeriği temel alan hizmetler, Google aramalarında daha fazla görünürlük elde etmek ister.
Ancak, Google aramalarında görünür olmak için, tarayıcıların sık sık siteyi ziyaret ederek en güncel verileri taraması ve bunu doğru şekilde yansıtması gerekir.
Bu noktada, tarayıcıların web sitesini daha sık ziyaret etmesini sağlamak için "Tarama Bütçesi" kavramı kullanılır. Daha yüksek bir bütçeye sahip olmak, daha sık ziyaret edilmeyi sağlar ve bunun için sitenin belirli bir düzeyde trafiğe sahip olması gerekir.
Peki, bu sınırlı "Tarama Bütçesi"ni aynı bütçe ile daha sık ziyaret edilmeyi sağlamak için nasıl verimli bir şekilde kullanabiliriz?
Bu, sitenin web sayfası yükleme hızının hızlı olması ile mümkün olur. Örneğin, sayfa indirme süresi 200 ms olan bir siteye göre, 20 ms olan bir site daha sık sayfa taraması yapar.
Durumis, temelde "küresel hizmet" sunmayı hedeflediği için, dünya genelinde 8 bölgede temel trafik hizmetini sağlıyor.
GCP Sunucu Bölgesi
Şu anda hizmetlerimiz, temel olarak Google'ın 40 Bölgesiarasından Asya'da Seul, Singapur, Mumbai, Avrupa'da Belçika, Amerika Birleşik Devletleri'nde Los Angeles ve Güney Karolina'daki bölgeleri kullanıyor. Dünya üzerinde nereden erişilirse erişilsin, genellikle yavaş bağlantı sorunu yaşanmaz.
Ancak, daha önce bahsettiğimiz nedenlerden dolayı, daha da uç bir hız için biraz daha ince ayar yapmaya karar verdik.
Şu anda hizmetlerimiz, ilk başlatıldığında URL tabanlı sistemden yeni bir alt alan adı tabanlı sisteme geçiş sürecinde olduğu için, bazı yönlendirmeler (Redirect) mevcuttur ve bu kısımda Google tarayıcılarının yoğun bir şekilde ziyaret ettiği gözlemlenmektedir. Mevcut URL'leri Google'a hızlı bir şekilde yeni URL'ler olarak tanıtıp kabul ettirilmemiz gerekiyor.
Bu nedenle, verilen tarayıcı bütçesini en üst düzeyde kullanmak için, yönlendirme (Redirect) trafiği için mümkün olan en hızlı hızı korumamız gerekiyor.
Daha önce, bahsedilen 8 bölgede GKE dağıtılmıştı ve her bir GKE, Google'ın GKE Otopilot özelliğini kullanarak, veritabanı ile bağlantısı olmayan verileri kullanarak yönlendirme işlemlerini gerçekleştiriyordu.
Bu nedenle, GKE'de bulunan ve daha önce Cloud Run'da bulunan bazı mantıksal yapıları yeni bir Cloud Run'a taşımaya karar verdik. Taşınacak liste şu şekildedir:
- robots.txt: Statik bir dosya olsa da, çeşitli alt alan adlarında belirli mantıksal yapılarla içerik sunuyor.
- favicon.ico: Saf statik dosya
- durumis.com/[lang]/@userId/postID: Yeni URL'ye yönlendirme (Redirect) -> userId.durumis.com/[lang]/postID
Daha önce, GKE Otopilot'ta bulunan biraz ağır bir çerçeve (framework) aracılığıyla sunum yapıldığında yaklaşık 200 ms'lik bir yanıt süresi gözlemlenmişti.
Yeni yöntemde Cloud Run kullanılıyor ve oldukça basit bir mantıksal yapı olduğu için çerçeve (framework) kullanılmıyor, node:http kullanılarak kitaplık (library) olmadan temel kodlar kullanılıyor.
const http = require("http"); const fs = require("fs"); const path = require("path"); let cachedFavicon = null; function loadFavicon() { const faviconPath = path.join(__dirname, "favicon.ico"); try { cachedFavicon = fs.readFileSync(faviconPath); console.log("Favicon loaded into memory"); } catch (err) { console.error("Error loading favicon:", err); } } --- 생략 --- const server = http.createServer((req, res) => { if (req.url === "/favicon.ico") { res.writeHead(200, { "Content-Type": "image/x-icon", "Cache-Control": "public,max-age=2419200" } res.end(cachedFavicon); }); server.listen(port, () => { console.log(Server running at http://localhost:${port}/); });
(Yukarıdaki kodu olduğu gibi kullanırsanız çalışmaz. Sadece genel kavramı anlamanız yeterlidir.)
Favicon.ico dosyası bir resim dosyası olduğu için, dosyadan yüklenerek belleğe (memory) yerleştiriliyor ve buradan gönderim yapılıyor.
Gcloud kullanarak birden fazla bölgeye eş zamanlı dağıtım yapmak için kabuk betiği (shell script) kullanılıyor.
İşte..
Bu şekilde dağıtımın sonucu şu şekildedir:
Cloud Run Ekranı
Amerika Birleşik Devletleri'ndeki "tüm bölgelere" ve her kıtaya göre Avrupa'da 2, Asya'da 2, Afrika'da 1 ve Güney Amerika'da 2 bölgeye dağıtım yapıldı. Aslında Serverless'ın avantajlarından biri de budur; böyle bir dağıtım yapsak bile maliyet hiç artmaz. (Aksine, daha yakın bölgedeki trafiği sunarsak maliyet azalabilir.)
Peki, bu sayede hız ne kadar arttı?
Sunucu tarafı yanıt süresi daha önce şöyleydi:
GKE Autopilot
Geliştirilmiş hız ise şöyledir:
Cloud Run Kullanılarak Statik Dosya
Elbette Cloud Run Serverless olduğu için soğuk başlatma (cold start) süresi olur diye düşünebilirsiniz ancak, belirli aralıklarla sürekli tarayıcı ziyaretlerinin olduğu bir durumda bu aslında büyük bir sorun teşkil etmez. GCP'nin Serverless özelliklerinden biri de budur; bekleme (Standby) ve boşta kalma (Idle) durumları arasında geçiş yaparak beklemede kalır. (Ayrıca maliyet de artmaz.)
Bir sonraki yazıda, yukarıdakilere benzer küçük statik dosyalar veya 301 yönlendirmesi (Redirect) yerine, resim dosyaları veya diğer dosyalar için nasıl bir yaklaşım kullanılabileceğini açıklayacağız.