- Dalam benchmark oleh pengembang independen Theo Browne, Cloudflare Workers menunjukkan performa hingga 3,5 kali lebih lambat dibanding Vercel Node.js
- Penyebab hasil benchmark tersebut berasal dari berbagai masalah pada infrastruktur, konfigurasi library, dan metodologi benchmark
- Berbagai peningkatan pada platform dan framework telah dilakukan, termasuk perbaikan algoritme penjadwalan, tuning garbage collector V8, dan optimasi OpenNext
- Berkat patch utama tersebut, saat ini selisih performa antara Cloudflare dan Vercel telah jauh berkurang di sebagian besar benchmark
- Ke depan, Cloudflare akan terus berkontribusi pada perbaikan infrastruktur dan framework terbuka, serta melanjutkan optimasi dan verifikasi benchmark
Ringkasan dan kontroversi benchmark
- Pada Oktober 2023, pengembang Theo Browne memublikasikan benchmark yang membandingkan kecepatan eksekusi JavaScript sisi server di Cloudflare Workers dan Vercel (berbasis AWS Lambda)
- Cloudflare Workers sama-sama berbasis mesin JavaScript V8 seperti Vercel, tetapi teramati mengalami penurunan performa hingga 3,5 kali
- Kesenjangan performa yang tidak wajar ini disebabkan oleh berbagai faktor seperti fine-tuning infrastruktur, perbedaan library JavaScript, dan masalah pada metode pengujian
- Dalam proses memperbaiki masalah-masalah tersebut, performa keseluruhan Cloudflare Workers ikut meningkat
- Di antara perbaikan utama, ada juga peningkatan yang bisa berdampak ke platform lain, seperti peningkatan kecepatan operasi trigonometri
Metodologi benchmark
- Klien pengujian awal Theo mengakses dari San Francisco melalui Webpass, sementara Vercel berjalan di region sfo1
- Di Cloudflare, komunikasi dilakukan langsung dengan instance iad1 milik Vercel di dalam data center AWS us-east-1 untuk meminimalkan dampak latensi jaringan
- Semua benchmark dijalankan dalam lingkungan single-thread (1 vCPU), sehingga perbandingan harga juga lebih mudah disejajarkan
- Bug yang ditemukan selama pengujian diajukan ke upstream melalui Pull Request dan telah diperbaiki
Peningkatan performa platform Cloudflare
Perbaikan penjadwalan dan penanganan isolasi di Workers Runtime
- Sebelumnya digunakan algoritme yang merutekan trafik ke isolasi "warm" (instance yang bisa memproses dengan cepat) untuk mengoptimalkan latensi dan throughput aplikasi berskala besar, tetapi ini tidak efisien untuk workload yang intensif CPU
- Saat banyak request dengan penggunaan CPU tinggi masuk, antrean menjadi panjang dan latensi meningkat, dan hal ini terlihat jelas dalam benchmark
- Cloudflare Workers menagih berdasarkan waktu penggunaan CPU, sehingga waktu tunggu (menunggu persiapan isolasi) tidak dikenai biaya
- Melalui perombakan algoritme, workload dengan penggunaan CPU tinggi kini dapat dideteksi lebih cepat dan isolasi baru bisa dibuat lebih cepat
- Pendekatan ini efektif untuk workload yang I/O-bound maupun CPU-bound, dan telah diterapkan secara global sehingga langsung berlaku
Perbaikan konfigurasi garbage collector V8
- Selama pengujian, terkonfirmasi bahwa isu garbage collection dan manajemen memori JavaScript sangat memengaruhi penurunan performa
- Ukuran area memori "young generation" pada mesin V8 dikunci terlalu ketat (mengikuti rekomendasi lama sebesar 128MB)
- Pada V8 modern, cara konfigurasi ini justru memicu GC yang sering terjadi tanpa perlu
- Tuning manual dinonaktifkan, dan V8 kini dibiarkan melakukan alokasi memori dinamis berbasis heuristiknya sendiri
- Hasilnya, terkonfirmasi ada peningkatan performa benchmark sekitar 25%, dan perubahan ini telah diterapkan ke semua Workers
Optimasi performa Next.js berbasis OpenNext
Menghapus alokasi dan penyalinan memori yang tidak perlu
- Hasil analisis menunjukkan bahwa 10–25% waktu pemrosesan request habis untuk pembebasan memori (GC)
- OpenNext, Next.js, dan React memiliki banyak pola kode yang menyalin buffer data internal secara berlebihan
- Terjadi penyalinan seluruh data output stream yang tidak perlu, serta penyalinan data dalam jumlah besar melalui
Buffer.concat hanya untuk mengukur panjang sederhana
- Isu-isu terkait sedang diperbaiki melalui Pull Request di repositori OpenNext
- Rencana peningkatan akan terus dilanjutkan agar perbaikan performa dapat dirasakan secara umum di seluruh platform
Optimasi adapter stream yang tidak efisien
- Workers menggunakan Web Streams API, sedangkan Next.js lebih banyak dirancang di atas stream API milik Node.js sehingga diperlukan adapter konversi
- Penggunaan adapter yang saling bertumpuk secara tidak perlu menyebabkan banyak overhead penyalinan memori dan buffering
- Kode disederhanakan menjadi
ReadableStream.from(chunks) untuk menghapus penyalinan di tengah proses
- Struktur stream nilai tunggal secara default (
highWaterMark=1) ditingkatkan menjadi byte stream (highWaterMark=4096 dan seterusnya) untuk mengoptimalkan pemrosesan data dalam jumlah besar
- Ke depan, patch peningkatan pemrosesan stream di Next.js dan React juga akan di-upstream ke platform yang lebih atas
Masalah performa JSON.parse() dan patch V8
- Di seluruh Next.js dan React, penggunaan JSON.parse() dengan opsi reviver menyebabkan pemanggilan berlebihan (lebih dari 100.000 kali)
- Dalam standar ECMAScript terbaru, reviver dapat menerima argumen ketiga (source context), yang makin memperburuk performa ini secara umum di Firefox, Chrome, dan lainnya
- Tim Cloudflare Workers memberikan patch ke mesin V8 (peningkatan performa 33%), yang nantinya juga akan menguntungkan seluruh ekosistem seperti Node.js, browser Chrome, dan Deno
Masalah performa fungsi trigonometri di Node.js
- Terpisah dari benchmark Theo, pada benchmark pemanggilan berulang fungsi trigonometri matematika (sin, cos, dll.), Cloudflare Workers dilaporkan 3 kali lebih cepat
- Penyebabnya adalah Node.js belum mengikuti jalur fungsi trigonometri terbaru/lebih cepat yang disediakan V8 (compile-time flag)
- Cloudflare Workers kebetulan mengaktifkan flag tersebut secara default, dan patch telah diajukan ke Node.js melalui Pull Request
- Karena masalah ini juga bersifat umum di ekosistem open source, diharapkan performa keseluruhan akan menjadi lebih stabil ketika diterapkan juga di AWS Lambda dan Vercel
Keterbatasan desain/pengukuran benchmark dan pelajarannya
- Sebagian besar benchmark mengukur waktu request (latency) dari sisi klien, bukan langsung mengukur waktu penggunaan CPU di sisi server
- Berbagai variabel yang sulit dibandingkan seperti rute jaringan, lokasi data center, generasi hardware, dan multi-tenancy dapat memengaruhi hasil
- Jika hanya mengukur time to first byte (TTFB), sulit merefleksikan total waktu rendering/pengiriman. Jika diganti ke TTFL, hasilnya bisa menjadi lebih sensitif terhadap perbedaan kecepatan jaringan
- Karena keragaman hardware/software server dan faktor keberuntungan dalam alokasi instance, ada juga noise sementara atau noise yang saling berkorelasi
- Dengan memperjelas lingkungan benchmark dan alur kerja, serta menyamakan variabel, tim dapat menemukan perbaikan yang berguna dalam praktik dan memberi manfaat baik untuk platform sendiri maupun platform lain
Masalah benchmark dan konfigurasi lingkungan yang ditemukan selama eksperimen
- Ada risiko salah tafsir hasil karena perbedaan seperti pengaturan force-dynamic di Next.js yang tidak diterapkan, logika cache, dan cara streaming respons
- Dalam benchmark React SSR, variabel lingkungan NODE_ENV tidak disetel sehingga berjalan dalam dev mode dan menghasilkan hasil yang lebih lambat dari kondisi sebenarnya
- Kesalahan-kesalahan ini diperbaiki dengan menyetel variabel lingkungan secara eksplisit
Rencana ke depan dan kesimpulan
- Berbagai peningkatan performa di Cloudflare Workers Runtime sudah diterapkan sepenuhnya, sehingga pengguna mendapat manfaat tanpa perlu tindakan tambahan
- Pull Request yang mencerminkan kode pengujian dan optimasi OpenNext telah diberikan kepada Theo
- Perbaikan tambahan direncanakan untuk menutup kesenjangan antara OpenNext dan Next.js berbasis Vercel
- Algoritme penjadwalan dan mesin open source (V8, Node.js) akan terus ditingkatkan sambil melanjutkan kontribusi ke komunitas
- Melalui benchmark dan profiling yang lebih baik, mereka berencana terus menemukan isu potensial lebih awal, mempertahankan budaya optimasi, dan berbagi hasilnya
Referensi dan tautan tambahan
1 komentar
Opini Hacker News
Bagus bahwa CF benar-benar berusaha meningkatkan produknya. Namun, perubahannya terjadi terlalu cepat sehingga sulit diikuti, dan sering kali rilis mendahului kematangan produk. Misalnya, R2 Data Catalog masih kekurangan dukungan Iceberg v3, Wrangler berubah besar hanya dalam beberapa bulan, dan Pages terasa seperti akan segera hilang sehingga migrasi ke Workers Assets sangat merepotkan. Konfigurasi yang berjalan baik di Wrangler 3 tidak diterapkan dengan benar di Wrangler 4, dan rasanya di Wrangler 5 akan muncul lagi model interaksi baru
Soal pernyataan "Pages terasa seperti akan hilang", di komunitas CF sebenarnya pernah disebutkan bahwa Pages tidak akan dihapus sampai Workers mencapai tingkat yang setara dengan Pages Postingan terkait Sulit menemukan pernyataan resmi bahwa Pages akan dihentikan, dan pages.cloudflare.com maupun developer.cloudflare.com/pages masih aktif dikelola. Ada satu postingan Reddit yang mengisyaratkan migrasi Pages, tetapi bahkan di tautan itu pun tidak ada penyebutan resmi soal penghentian Saya setuju dengan komentar lainnya, dan terutama bagian itu yang cukup mengejutkan bagi saya Tautan referensi Reddit
Saya tidak setuju dengan pernyataan bahwa konfigurasi Wrangler 3 tidak tetap berjalan di Wrangler 4. Di Wrangler 4 tidak ada perubahan sama sekali pada format konfigurasi, dan alasan kenaikan major version tidak berdampak pada 99,99% pengguna. Rincian perubahannya bisa dilihat di sini. Kenaikan major version saja memang sudah cukup merepotkan sehingga saya sendiri juga pernah menyampaikan keberatan, tetapi tim bersikap hati-hati karena ada kasus pengecualian yang sangat jarang. Ke depannya, kami akan mengembangkan cara untuk menangani isu seperti ini tanpa kenaikan major version, misalnya dukungan paralel untuk versi esbuild. Dari sisi runtime, kami sangat serius menjaga kompatibilitas mundur Blog tentang kompatibilitas mundur Pages tidak akan hilang, dan Workers Assets adalah versi implementasi Pages yang lebih fleksibel. Jika Anda tidak membutuhkan fitur tambahan, tidak perlu buru-buru pindah, dan nantinya juga akan ada migrasi otomatis
Ini kembali mengingatkan bahwa saat membangun proyek penting atau sistem yang akan dipelihara selama beberapa tahun, lebih baik memakai 'teknologi membosankan' (boring tech)
Saya penasaran, dari mana dasar anggapan "Pages akan hilang" itu. Saya sendiri memakai Pages dengan baik di beberapa proyek
Hal yang menarik adalah kontroversi ini berawal dari klaim bahwa Cloudflare lebih cepat daripada Vercel. Lalu seseorang yang benar-benar paham melakukan benchmark dan hasil nyatanya justru kebalikan, sehingga pada akhirnya Cloudflare benar-benar melakukan perbaikan untuk meningkatkan performa
Saya sangat suka bahwa artikel ini tidak menyerang pesaing, melainkan mencari dan menyoroti hal-hal yang bisa diperbaiki. Perkembangan pada implementasi OpenNext juga mengesankan, terutama karena bisa dimanfaatkan kembali oleh penyedia lain
Saya sedang memindahkan hosting NextJS dari Vercel ke Astro/React di Cloudflare. Yang mengejutkan, bahkan dalam situasi merender web app di “edge” pada setiap permintaan, waktu responsnya sekitar 100-200ms, jadi nyaris sebanding dengan halaman statis. Dalam beberapa minggu terakhir saya juga benar-benar merasakan peningkatan pada Cloudflare Worker: cold start hampir hilang dan kecepatan respons jauh lebih stabil Tautan web app yang sedang dipindahkan
Menarik melihat bagaimana video dari YouTuber yang tidak terlalu besar bisa menyebar secara efektif seperti ini, lalu mendorong Cloudflare melakukan perbaikan yang benar-benar bermakna dan menyelesaikan isu platform
PR ini disusun dengan sangat baik. Pujian untuk orang-orang yang menyiapkan postingan ini
Sebagai pelanggan cf lama, menurut saya cf bukan hanya jago menulis blog dan open source, tetapi juga terbaik di antara perusahaan infrastruktur dalam hal dukungan layanan. Anggota timnya, termasuk kenton, sering langsung membantu pengguna atau menerima masukan di Discord, dan untuk bug atau isu kita sering bisa langsung berkomunikasi dengan engineer yang benar-benar menangani masalahnya. Bahkan PR atau permintaan fitur yang saya usulkan sendiri pernah cepat diterapkan tanpa proses yang rumit. Dengan tarif yang sangat murah dibanding perusahaan besar lain, saya justru mendapat dukungan yang jauh lebih baik
Terima kasih! PR dan postingan ini sepenuhnya digagas dan dibuat langsung oleh para engineer tim Workers (saya juga ikut terlibat)
Saya sangat menyukai cara postingan ini ditulis, bagaimana informasinya dipecah, dan diskusi terbukanya. Kepercayaan saya pada tim Cloudflare workers meningkat
Menurut saya SvelteKit sangat cepat, sedangkan Next.js relatif sangat lambat
Kesimpulan yang masuk akal
Saya berharap framework yang lebih praktis seperti SvelteKit, Astro, dan TanStack segera menggantikan kompleksitas NextJS
Inilah contoh mengapa persaingan dan benchmark independen itu diperlukan. Layanan dengan performa kurang pun jadi terdorong untuk memperbaiki diri
Upaya seperti itu pun hanya efektif kalau produknya benar-benar dipedulikan
Benchmark independen sebenarnya sudah ada
Saya terkesan bahwa Cloudflare menerima hasilnya dengan rendah hati dan melakukan perbaikan secara konstruktif
Tulisan yang bagus karena fokus pada substansi dan tidak saling menyalahkan. Tetapi saya cukup heran Cloudflare sebelumnya tidak memantau dan menyesuaikan hal seperti ukuran generation dengan lebih baik. Dalam pengalaman saya melakukan tuning performa JVM, pengaturan generation size itu dasar sekali