- Bağımsız geliştirici Theo Browne'un benchmark'ında Cloudflare Workers'ın Vercel Node.js'e kıyasla en fazla 3,5 kat daha yavaş performans gösterdiği görüldü
- Benchmark sonuçlarının nedeni, çeşitli altyapı·kütüphane ayarları ve benchmark metodolojisindeki sorunlardı
- Zamanlama algoritmasının iyileştirilmesi, V8 çöp toplayıcısının ayarlanması, OpenNext optimizasyonu gibi çok sayıda platform ve framework iyileştirmesi yapıldı
- Başlıca yamalar sayesinde şu anda benchmark'ların çoğunda Cloudflare ile Vercel arasındaki performans farkı büyük ölçüde azaldı
- Cloudflare bundan sonra da açık altyapı ve framework iyileştirmelerine katkı sunarak, sürekli optimizasyon ve benchmark doğrulamasını sürdürmeyi planlıyor
Genel bakış ve benchmark tartışması
- Ekim 2023'te geliştirici Theo Browne, Cloudflare Workers ile Vercel'in (AWS Lambda tabanlı) sunucu tarafı JavaScript çalıştırma hızını karşılaştıran bir benchmark yayımladı
- Cloudflare Workers da Vercel gibi V8 JavaScript motorunu temel almasına rağmen, en fazla 3,5 katlık performans düşüşü gözlemlendi
- Altyapı mikro ayarları, JavaScript kütüphane farkları, test yöntemi sorunları gibi çeşitli nedenlerle makul olmayan bir performans farkı ortaya çıktı
- Bu sorunlar iyileştirilirken Cloudflare Workers'ın genel performansı da arttı
- Başlıca düzeltmeler arasında, trigonometrik fonksiyon işlemlerinin hızlandırılması gibi başka platformları da etkileyebilecek geliştirmeler de yer aldı
Benchmark metodolojisi
- Theo'nun ilk test istemcisi San Francisco'dan Webpass üzerinden erişiyordu; Vercel ise sfo1 bölgesinde çalışıyordu
- Cloudflare tarafında, ağ gecikmesinin etkisini en aza indirmek için AWS us-east-1 veri merkezinden Vercel'in iad1 instance'ı ile doğrudan iletişim kuruldu
- Benchmark'ların tamamı tek iş parçacıklı (
vCPU 1 adet) ortamda yapıldı; böylece fiyat karşılaştırması da kolaylaştı
- Test sırasında bulunan hatalar upstream'e Pull Request olarak gönderildi ve düzeltildi
Cloudflare platformundaki performans iyileştirmeleri
Workers Runtime'ın zamanlama ve izolasyon işleme iyileştirmeleri
- Önceden, trafiği "warm" izolasyonlara (hızlı işlenebilen instance'lar) yönlendiren bir algoritma kullanılarak büyük uygulamalarda gecikme ve throughput optimize ediliyordu; ancak bu yaklaşım CPU yoğun iş yüklerinde verimsizdi
- CPU kullanımı yüksek istekler yığıldığında kuyruk uzuyor ve gecikme artıyordu; benchmark bunu görünür hale getirdi
- Cloudflare Workers'ta faturalandırma ölçütü CPU kullanım süresi olduğu için, bekleme süresi (izolasyonun hazırlanmasını bekleme) ücretlendirilmiyor
- Algoritmanın yeniden düzenlenmesiyle, CPU kullanımı yüksek iş yükleri daha hızlı algılanıp yeni izolasyonlar daha hızlı oluşturulur hale getirildi
- Hem I/O-bound hem de CPU-bound iş yüklerine verimli biçimde yanıt verecek şekilde iyileştirme yapıldı ve bu değişiklik küresel olarak anında devreye alındı
V8 çöp toplayıcı ayarlarının iyileştirilmesi
- Test sürecinde JavaScript çöp toplama ve bellek yönetimi sorunlarının performans düşüşünde büyük etkisi olduğu görüldü
- V8 motorunun "young generation" bellek alanı boyutu ayarı fazla kısıtlayıcı biçimde sabitlenmişti (geçmişte önerilen 128 MB'a göre)
- Güncel V8'de bu ayar yöntemi tersine gereksiz sıklıkta GC çalışmasına yol açıyordu
- Elle yapılan ayar kaldırıldı ve V8'in kendi sezgisel tabanlı dinamik bellek tahsisine izin verildi
- Yaklaşık %25 benchmark performans artışı doğrulandı ve tüm Workers ortamına uygulandı
OpenNext tabanlı Next.js performans optimizasyonu
Gereksiz bellek tahsisi ve kopyalamanın kaldırılması
- Analiz sonucunda, istek işleme süresinin %10–25'inin bellek geri kazanımına (GC) harcandığı görüldü
- OpenNext, Next.js ve React içinde dahili veri tamponlarını aşırı kopyalayan çok sayıda kod deseni vardı
- Akış çıktısının tamamını gereksiz yere kopyalama,
Buffer.concat ile yalnızca uzunluk ölçümü amacıyla büyük miktarda veri kopyalama gibi durumlar vardı
- İlgili sorunlar OpenNext deposuna Pull Request ile iyileştiriliyor
- Tüm platform genelinde ortak performans iyileşmesi sağlanabilmesi için çalışmaların sürdürülmesi planlanıyor
Verimsiz stream adapter'larının optimizasyonu
- Workers Web Streams API kullanırken, Next.js daha çok Node.js stream API etrafında tasarlandığı için dönüştürücü adapter'lara ihtiyaç duyuluyordu
- Gereksiz şekilde iç içe adapter kullanımı, çok sayıda bellek kopyalama ve buffering overhead'i oluşturuyordu
- Kod yalnızca
ReadableStream.from(chunks) kullanılarak sadeleştirildi ve ara kopyalamalar kaldırıldı
- Varsayılan tek değerli stream (
highWaterMark=1) yapısı, büyük veri işlemesini optimize etmek için byte stream'e (highWaterMark=4096 vb.) dönüştürüldü
- Gelecekte Next.js ve React'in stream işleme iyileştirmelerine yönelik yamaların da üst platformlara upstream edilmesi planlanıyor
JSON.parse() performans sorunu ve V8 yaması
- Next.js ve React genelinde reviver seçeneği içeren
JSON.parse() kullanımında aşırı çağrı oluşuyordu (100.000'den fazla)
- Güncel ECMAScript standardıyla reviver'ın üçüncü argüman olarak source context alabilmesi, performansı ek olarak kötüleştirdi (Firefox, Chrome vb. genelinde)
- Cloudflare Workers ekibi V8 motoruna bir yama sundu (%33 performans iyileşmesi); bunun Node.js, Chrome tarayıcısı, Deno ve tüm ekosisteme fayda sağlaması bekleniyor
Node.js'in trigonometrik fonksiyon performansı sorunu
- Theo'nun benchmark'ından ayrı olarak, matematiksel trigonometrik fonksiyonların (
sin, cos vb.) tekrarlı çağrıldığı benchmark'ta Cloudflare Workers'ın 3 kat daha hızlı olduğu bildirildi
- Bunun nedeni, Node.js'in V8'de sunulan en güncel/yüksek hızlı trigonometrik fonksiyon yolunu (compile-time flag) henüz kullanmıyor olmasıydı
- Cloudflare Workers bu flag'i tesadüfen varsayılan olarak etkinleştirmişti; Node.js'e ise Pull Request ile yama gönderildi
- Bu sorun da açık kaynak ekosisteminin genelini ilgilendirdiği için, AWS Lambda ve Vercel'e de yansıdığında genel hız kararlılığının artması bekleniyor
Benchmark tasarımı/ölçümündeki sınırlamalar ve çıkarılan dersler
- Benchmark'lar çoğunlukla istemci tarafında istek süresini (latency) ölçme yöntemine dayanıyordu; gerçek sunucu tarafı CPU kullanım süresi doğrudan ölçülmüyordu
- Ağ yolu, veri merkezi konumu, donanım nesli, multi-tenancy gibi çeşitli doğrudan karşılaştırılamayan değişkenler sonucu etkileyebiliyor
- Yalnızca ilk bayta ulaşma süresi (TTFB) ölçüldüğünde, toplam render/aktarım süresini yansıtmak zorlaşıyor. TTFL'ye geçildiğinde ise ağ hızı farklarına daha duyarlı olunabiliyor
- Sunucu donanımı/yazılımı çeşitliliği ve instance tahsisindeki rastlantısal etkenler nedeniyle geçici ve ilişkili gürültü de bulunuyor
- Benchmark ortamı ve iş akışlarının netleştirilmesi, değişkenlerin hizalanması sürecinde pratik iyileştirme noktaları ortaya çıkarıldı; bu da hem kendi platformlarına hem de diğer platformlara fayda sağladı
Deney sırasında bulunan benchmark ve ortam ayarı sorunları
- Next.js'teki force-dynamic ayarının uygulanmaması, cache işleme mantığı ve yanıt streaming yöntemi farkları nedeniyle sonuçların yanlış yorumlanma riski vardı
- React SSR benchmark'ında
NODE_ENV ortam değişkeni ayarlanmadığı için dev mode çalışıyor ve gerçekte olduğundan daha yavaş sonuç dönüyordu
- Bu hatalar, ortam değişkenlerinin açıkça ayarlanmasıyla düzeltildi
Gelecek planı ve sonuç
- Cloudflare Workers Runtime'daki çeşitli performans iyileştirmeleri zaten tamamen devreye alındı; kullanıcılar ek bir işlem yapmadan bundan faydalanıyor
- Theo'ya test kodu ve OpenNext optimizasyonlarını içeren Pull Request'ler sağlandı
- OpenNext ile Vercel tabanlı Next.js arasındaki farkı kapatmaya yönelik ek iyileştirmeler planlanıyor
- Zamanlama algoritması ile açık kaynak motorlarda (V8, Node.js) sürekli yükseltme ve topluluğa katkı politikası sürdürülecek
- Daha iyi benchmark ve profiling ile potansiyel sorunların erken tespiti, optimizasyon ve paylaşım kültürünün korunması hedefleniyor
Referans materyaller ve ek bağlantılar
1 yorum
Hacker News görüşü
CF'nin gerçekten ürünü iyileştirmek için çaba göstermesi güzel. Ancak değişim çok hızlı yaşanıyor ve yetişmek zor; ayrıca çoğu zaman çıkışlar olgunluğun önüne geçiyor. Örneğin R2 Data Catalog'da hâlâ Iceberg v3 desteği eksik, Wrangler ise yalnızca birkaç ay içinde büyük ölçüde değişti ve Pages yakında ortadan kalkacakmış gibi göründüğü için Workers Assets'e geçiş oldukça zahmetli. Wrangler 3'te sorunsuz çalışan ayarlar Wrangler 4'te düzgün uygulanmadı ve Wrangler 5'te de yine yeni bir etkileşim modeli gelecekmiş gibi hissettiriyor
"Pages yakında ortadan kalkacakmış gibi" ifadesiyle ilgili olarak, CF topluluk gönderilerinde Workers, Pages ile aynı seviyeye gelene kadar Pages'i kaldırmayacaklarını belirtmişti İlgili gönderi Resmî olarak Pages'in kullanımdan kaldırılacağına dair bir şey bulmak zor; pages.cloudflare.com ile developer.cloudflare.com/pages de aktif şekilde işletiliyor. Reddit'teki bir gönderi Pages geçişini ima ediyor, ancak o bağlantıda da resmî bir sonlandırma ifadesi yok Diğer görüşlerin geri kalanına katılıyorum; özellikle bu kısım beni şaşırttı Reddit referans bağlantısı
Wrangler 3 yapılandırmasının Wrangler 4'te aynı şekilde çalışmadığı sözüne katılamıyorum. Wrangler 4'te yapılandırma biçiminde hiçbir değişiklik olmadı ve major sürüm artışının nedeni kullanıcıların %99,99'u için etkisizdi. İlgili değişiklik notlarına buradan bakılabilir. Sadece major sürüm yükseltmesinin bile rahatsızlık yarattığını düşündüğüm için ben de buna karşı çıkmıştım, ancak ekip son derece nadir görülen istisna durumlar nedeniyle temkinli davrandı. İleride bu tür meseleleri major sürüm yükseltmesi olmadan yönetmenin yollarını geliştireceğiz; örneğin esbuild sürümlerine paralel destek gibi. Runtime tarafında ise özellikle geriye dönük uyumluluğa çok büyük önem veriyoruz Geriye dönük uyumlulukla ilgili blog Pages ortadan kalkmıyor; Workers Assets, Pages'in daha esnek bir uygulama sürümü. Ek işlevlere ihtiyacınız yoksa geçmek zorunda değilsiniz ve ileride otomatik geçiş de yapılacak
Önemli projeler ya da yıllarca sürdürülecek sistemler inşa ederken bir kez daha "boring tech" kullanmanın iyi olduğunu hatırlatıyor
"Pages yakında ortadan kalkacakmış gibi" sonucuna hangi dayanakla vardığınızı merak ediyorum. Ben birkaç projede Pages'i gayet iyi kullanıyorum
İlginç olan şu ki bu tartışma, Cloudflare'in Vercel'den daha hızlı olduğu iddiasıyla başladı. Sonra konuyu gerçekten bilen biri bir benchmark yaptı ve gerçekte sonucun tam tersi olduğu ortaya çıktı; bunun sonucunda da Cloudflare performansı artırmak için gerçekten iyileştirme çalışmalarına girişti
Yazıda rekabeti kötülemek yerine iyileştirme noktalarını bulup öne çıkaran tavrı gerçekten beğendim. OpenNext uygulamasında da ilerleme olması ve bunun başka sağlayıcılar tarafından da yeniden kullanılabilecek olması etkileyici
NextJS'yi Vercel'de barındırıyordum, şimdi Astro/React'i Cloudflare'e taşıyorum. Şaşırtıcı olan şey, her istekte web uygulamasını "edge" üzerinde render eden bir durumda bile yanıt süresinin 100-200 ms civarında olması; neredeyse statik sayfalarla yarışacak kadar hızlı. Son birkaç haftada Cloudflare Worker tarafındaki iyileştirmeleri de net biçimde hissettim; cold start neredeyse ortadan kalktı ve yanıt süreleri çok daha istikrarlı hale geldi Taşınmakta olan web uygulaması bağlantısı
Büyük ölçekli olmayan bir YouTuber'ın yüklediği bir videonun bu şekilde etkili biçimde yayılması ve bunun Cloudflare tarafında gerçekten anlamlı iyileştirmelere ve platform sorunlarının çözümüne yol açması ilginç
Çok iyi hazırlanmış bir PR. Bu gönderiyi hazırlayanları tebrik ederim
Eski bir cf müşterisi olarak şunu söyleyeyim: cf yalnızca blog ve açık kaynak yazılarında değil, altyapı şirketleri arasında hizmet desteğinde de en iyisi. Ekip üyeleri (Kenton dahil) çoğu zaman Discord'da doğrudan kullanıcılara yardım ediyor veya geri bildirimleri dikkate alıyor; hata ve sorunlarda da doğrudan ilgili mühendisle konuşabiliyorsunuz. Hatta benim önerdiğim PR'lar veya özellik istekleri bile özel bir süreç olmadan hızlıca yansıtılmıştı. Diğer büyük şirketlere kıyasla çok daha ucuz bir ücretlendirme ile çok daha iyi destek alıyorum
Teşekkürler! Bu PR ve gönderi tamamen Workers ekibindeki mühendisler tarafından proaktif şekilde planlandı ve hazırlandı (%100); ben de katkıda bulundum
Bu gönderinin yazım biçimini, bilgiyi parçalayışını ve açık tartışma yaklaşımını gerçekten beğendim. Cloudflare workers ekibine olan güvenim arttı
Bence SvelteKit inanılmaz hızlı ve Next.js buna kıyasla oldukça yavaş
Makul bir sonuç
Umarım SvelteKit, Astro ve TanStack gibi pratik framework'ler yakında NextJS'nin karmaşıklığının yerini alır
Bu tür örnekler, rekabetin ve bağımsız benchmark'ların neden gerekli olduğunu gösteriyor. Performansı yetersiz olan hizmetleri bile iyileşmeye zorlayabiliyor
Ama böyle çabaların etkili olabilmesi için ürünün gerçekten önemsenmesi gerekir
Bağımsız benchmark'lar zaten var
Cloudflare'in sonuçları alçakgönüllülükle kabul edip yapıcı şekilde iyileştirmeler yapması etkileyici
İçeriğe odaklanan ve suçlayıcı olmayan harika bir yazı. Ama Cloudflare'in generation size gibi şeyleri önceden daha iyi izleyip ayarlamamış olması şaşırtıcıydı. JVM performans ayarında generation size belirlemek benim deneyimimde oldukça temel bir şeydi