İnternet altyapısında “birkaç yüz bayt” önemsiz görünebilir. Fakat aynı veri yapısı yüz milyarlarca kez tekrarlandığında, küçük bir fazlalık veri merkezi ölçeğinde ciddi bir maliyete dönüşür. Cloudflare’ın 27 Ağustos 2026’da yayımladığı teknik inceleme tam olarak bunu gösteriyor: 1.1.1.1 DNS çözümleyicisinin önbellek platformunda kayıt başına yapılan düzenlemeler, toplam çalışma belleğini yaklaşık 100 terabayt azalttı. Bu yazı, sonucu bir başarı hikâyesi olarak tekrarlamak yerine kullanılan ölçüm mantığını ve Türkiye’deki yazılım ekiplerinin çıkarabileceği dersleri açıklıyor.

Önce ölçeği doğru okuyalım

Cloudflare’ın “Big Pineapple” adını verdiği dağıtık platform, 250 milyardan fazla DNS önbellek girdisi tutuyor. Şirketin verdiği sayılara göre bir girdinin net bellek ayak izi 953 bayttan 420 bayta, girdiye bağlı toplam tahsis ise yaklaşık 1,1 kilobayttan 461 bayta indi. Bu sırasıyla yüzde 56 ve yüzde 58 azalma demek.

Rakamlar yalnız laboratuvar ölçümü değil. Değişiklikler 18 Mayıs ile 6 Temmuz 2026 arasında kademeli olarak canlı sisteme dağıtıldı. Üretim telemetrisinde süreç başına p99 bellek kullanımı 9,3 GB’tan 5,3 GB’a; p90 ise 6,5 GB’tan 3,8 GB’a geriledi. “Yaklaşık 100 TB” sonucu, bu dağıtık sistemin toplam çalışma kümesine ilişkin Cloudflare’ın kendi hesabıdır; her DNS sunucusunun bu kadar RAM kullandığı anlamına gelmez.

Bellek nerede kayboluyordu?

Asıl ders tek bir sihirli algoritma değil, küçük maliyetlerin birlikte ele alınması. DNS yanıtları değişken uzunlukta veriler taşır. Bir uygulama her kayıt için gereğinden geniş alan ayırdığında, işaretçiler ve ayrı bellek tahsisleri kullandığında, gerçek veriden çok onu taşıyan yapıya ödeme yapabilir.

Cloudflare beş sınıfta değişiklik anlatıyor: veri yapılarının sıkılaştırılması, küçük değerlerin doğrudan yapı içine alınması, tekrar eden alanların azaltılması, tahsis stratejisinin değiştirilmesi ve önbellek davranışının yeniden ayarlanması. Bu yaklaşım “her şeyi sıkıştır” demiyor. Hangi alanın ne sıklıkta kullanıldığını ölçüp, erişim hızını bozmadan temsili küçültüyor.

Bellek azalırken hız neden düşmedi?

Kompakt yapıların daha yavaş olacağı varsayımı her zaman doğru değil. Daha küçük veriler işlemci önbelleğine daha iyi sığabilir ve ayrı tahsis sayısı azaldığında bellek yöneticisinin yükü düşebilir. Cloudflare’ın testlerinde ekleme hızı saniyede 625 bin girdiden 893 bin girdiye çıktı; yaklaşık yüzde 43 artış. Arama gecikmesi de 828 nanosaniyeden 670 nanosaniyeye, yüzde 19 oranında indi.

Bu sonuçların Cloudflare’ın donanımı, iş yükü ve uygulama koduna ait olduğunu unutmamak gerekir. Aynı oranları kendi sisteminize yazamazsınız. Kopyalanabilecek şey rakam değil, önce kıyaslama testi kurup sonra değişikliği üretim telemetrisiyle doğrulama yöntemidir.

Türkiye’deki ekipler için üç pratik ders

1. Birim maliyeti tekrar sayısıyla çarpın

E-ticaret kataloğunda ürün, telekom sisteminde oturum, reklam platformunda olay kaydı veya log hattında etiket gibi çok tekrarlanan nesneleri bulun. Bir nesnenin “yalnızca” 200 bayt fazla olması, 100 milyon nesnede yaklaşık 20 GB ek yük anlamına gelir. Bulut faturası dövizle ödeniyorsa bu fark yalnız teknik değil, bütçesel bir risktir.

2. Ortalama tek başına yetmez

Ortalama bellek kullanımı sakin saatleri parlatabilir. Cloudflare’ın p90 ve p99 değerlerini paylaşması bu nedenle önemli. Kapasite planında yüksek yüzdelikler, yoğun saatlerde süreçlerin öldürülmesi veya yeniden başlatılması riskini daha iyi gösterir. Türkiye’de kampanya, maç yayını veya sınav sonucu gibi ani trafik yaratan servislerde tepe davranışını ayrıca ölçün.

3. DNS sorunuyla uygulama sorununu ayırın

Bu optimizasyon 1.1.1.1’in iç mimarisiyle ilgili; kullanıcının bağlantısını otomatik olarak hızlandıracağı garantisi yok. Ev veya ofiste “Wi-Fi bağlı ama internet yok” durumunda önce modem, ağ geçidi ve DNS çözümlemesini ayrı ayrı test etmek gerekir. Bu ayrımı uygulamak için Mac’te Wi-Fi bağlıyken internet sorununu çözme rehberindeki adımlar yararlı bir başlangıçtır.

Kendi servisinizde 30 dakikalık test

  1. En çok çoğalan üç nesne tipini ve canlıdaki yaklaşık adetlerini çıkarın.
  2. Dilinizin profiler aracıyla nesnenin gerçek tahsis boyutunu ölçün; yalnız kaynak koddaki alanları toplamayın.
  3. İşaretçi, boş kapasite, tekrar eden metin ve ayrı tahsisleri listeleyin.
  4. Mevcut sürüm için bellek, ekleme hızı ve arama gecikmesinden bir temel ölçüm alın.
  5. Tek değişiklik uygulayıp aynı veri dağılımıyla testi tekrarlayın.
  6. Ortalama yanında p90/p99 bellek ve gecikmeyi kaydedin.
  7. Küçük bir canlı trafik yüzdesinde gözlem yapmadan tüm sisteme dağıtmayın.

Test verisinin gerçek dağılıma benzemesi kritik. Yalnız kısa anahtarlarla yapılan sentetik test, uzun alan adları veya değişken DNS kayıtlarıyla karşılaşınca yanıltabilir. Ayrıca bellek kazancı uğruna kodun güvenliğini, okunabilirliğini ya da hata toleransını feda etmeyin.

Kısa kontrol listesi

  • Optimizasyon yapılan nesnenin canlıdaki tekrar sayısı biliniyor mu?
  • Net veri boyutu ile toplam tahsis ayrı ölçüldü mü?
  • Hız testi aynı donanım ve aynı veri dağılımıyla yapıldı mı?
  • Ortalama yanında p90 ve p99 izlendi mi?
  • Kademeli dağıtım ve geri dönüş planı hazır mı?
  • Kazanç, üretim telemetrisiyle doğrulandı mı?

Cloudflare örneğinin güçlü yanı “100 TB” başlığından çok, bayt düzeyindeki kararı milyarlarca tekrar ve üretim yüzdelikleriyle ilişkilendirmesi. Büyük sistemlerde performans çoğu zaman tek bir dev sıçramadan değil, doğru yerde tekrarlanan küçük israfı görünür kılmaktan gelir.

Kaynak