- Trong benchmark của nhà phát triển độc lập Theo Browne, Cloudflare Workers cho thấy hiệu năng chậm hơn Vercel Node.js tới 3,5 lần
- Nguyên nhân của kết quả benchmark xuất phát từ nhiều vấn đề về cấu hình hạ tầng, thư viện và phương pháp luận benchmark
- Nhiều cải tiến trên nền tảng và framework đã được thực hiện như cải thiện thuật toán lập lịch, tinh chỉnh bộ gom rác V8, tối ưu hóa OpenNext
- Nhờ các bản vá quan trọng, hiện nay chênh lệch hiệu năng giữa Cloudflare và Vercel trong phần lớn benchmark đã giảm đáng kể
- Trong thời gian tới, Cloudflare sẽ tiếp tục đóng góp cho hạ tầng công khai và cải tiến framework, đồng thời duy trì tối ưu hóa liên tục và kiểm chứng benchmark
Tổng quan và tranh cãi quanh benchmark
- Vào tháng 10/2023, nhà phát triển Theo Browne đã công bố một benchmark so sánh tốc độ thực thi JavaScript phía máy chủ của Cloudflare Workers và Vercel (dựa trên AWS Lambda)
- Cloudflare Workers cũng dùng động cơ JavaScript V8 như Vercel, nhưng quan sát cho thấy hiệu năng có lúc thấp hơn tới 3,5 lần
- Khoảng cách hiệu năng thiếu hợp lý này xuất phát từ nhiều nguyên nhân như tinh chỉnh hạ tầng ở mức vi mô, khác biệt thư viện JavaScript và vấn đề trong cách thử nghiệm
- Trong quá trình xử lý các vấn đề đó, hiệu năng tổng thể của Cloudflare Workers đã được cải thiện
- Một số thay đổi quan trọng còn bao gồm các tối ưu có thể ảnh hưởng tới nền tảng khác, chẳng hạn như cải thiện tốc độ tính toán hàm lượng giác
Phương pháp benchmark
- Client thử nghiệm ban đầu của Theo truy cập từ San Francisco qua Webpass, còn Vercel chạy tại vùng sfo1
- Ở phía Cloudflare, việc liên lạc trực tiếp với instance iad1 của Vercel trong trung tâm dữ liệu AWS us-east-1 đã giúp giảm thiểu ảnh hưởng của độ trễ mạng
- Tất cả benchmark đều được thực hiện trong môi trường đơn luồng (1 vCPU), giúp việc so sánh chi phí cũng trở nên dễ dàng hơn
- Các lỗi phát hiện trong quá trình thử nghiệm đã được gửi upstream dưới dạng Pull Request và được sửa
Cải thiện hiệu năng của nền tảng Cloudflare
Cải thiện lập lịch và xử lý cô lập trong Workers Runtime
- Trước đây, hệ thống dùng thuật toán định tuyến lưu lượng tới các vùng cô lập "ấm" (instance có thể xử lý nhanh) để tối ưu độ trễ và thông lượng cho các ứng dụng lớn, nhưng lại kém hiệu quả với workload thiên về CPU
- Khi nhiều request chiếm CPU lớn dồn tới cùng lúc, hàng đợi trở nên dài hơn và độ trễ tăng lên; điều này đã lộ rõ trong benchmark
- Vì Cloudflare Workers tính phí theo thời gian sử dụng CPU, nên thời gian chờ (đợi vùng cô lập sẵn sàng) không bị tính phí
- Thông qua việc cải tổ thuật toán, hệ thống được cải thiện để phát hiện sớm hơn các workload dùng CPU nhiều và tạo vùng cô lập mới nhanh hơn
- Cách làm này xử lý hiệu quả cả workload I/O-bound lẫn CPU-bound, và đã được triển khai toàn cầu để có hiệu lực ngay
Cải thiện cấu hình bộ gom rác V8
- Trong quá trình thử nghiệm, nhóm xác nhận rằng các vấn đề liên quan đến garbage collection và quản lý bộ nhớ của JavaScript ảnh hưởng lớn tới suy giảm hiệu năng
- Thiết lập kích thước vùng nhớ "young generation" của động cơ V8 đã bị cố định quá chặt (theo mức khuyến nghị cũ là 128MB)
- Trên V8 hiện đại, cách cấu hình này lại gây ra GC thường xuyên không cần thiết
- Hệ thống đã bỏ tinh chỉnh thủ công và cho phép V8 tự phân bổ bộ nhớ động dựa trên heuristic của chính nó
- Kết quả ghi nhận cải thiện khoảng 25% hiệu năng benchmark, và thay đổi này đã được áp dụng cho toàn bộ Workers
Tối ưu hiệu năng Next.js dựa trên OpenNext
Loại bỏ cấp phát và sao chép bộ nhớ không cần thiết
- Kết quả phân tích cho thấy 10–25% thời gian xử lý request bị tiêu tốn cho việc giải phóng bộ nhớ (GC)
- OpenNext, Next.js và React có nhiều mẫu mã nội bộ sao chép buffer dữ liệu quá mức
- Có các thao tác sao chép toàn bộ dữ liệu đầu ra của stream một cách không cần thiết, cũng như sao chép lượng lớn dữ liệu bằng
Buffer.concat chỉ để đo độ dài đơn thuần
- Các vấn đề liên quan đang được cải thiện bằng Pull Request gửi tới kho lưu trữ OpenNext
- Kế hoạch là tiếp tục nâng cấp để cải thiện hiệu năng theo cách có thể áp dụng chung trên toàn nền tảng
Tối ưu adapter stream kém hiệu quả
- Workers dùng Web Streams API, trong khi Next.js chủ yếu được thiết kế quanh stream API của Node.js, nên cần có adapter chuyển đổi
- Việc dùng adapter lồng nhau không cần thiết đã tạo ra nhiều overhead do sao chép bộ nhớ và buffering
- Chỉ bằng cách rút gọn mã thành
ReadableStream.from(chunks), hệ thống đã loại bỏ được các bước sao chép trung gian
- Cấu trúc stream mặc định xử lý từng giá trị đơn lẻ (
highWaterMark=1) cũng được cải thiện thành stream theo byte (highWaterMark=4096 v.v.) để tối ưu xử lý dữ liệu lớn
- Trong tương lai, các bản vá cải thiện xử lý stream của Next.js và React cũng sẽ được đẩy upstream lên các nền tảng cấp trên
Vấn đề hiệu năng của JSON.parse() và bản vá cho V8
- Trên toàn bộ Next.js và React, việc dùng
JSON.parse() kèm tùy chọn reviver gây ra số lần gọi quá nhiều (hơn 100.000 lần)
- Trong tiêu chuẩn ECMAScript mới nhất, reviver có thể nhận thêm tham số thứ ba (source context), khiến hiệu năng giảm thêm trên diện rộng (Firefox, Chrome, v.v.)
- Nhóm Cloudflare Workers đã đóng góp bản vá cho động cơ V8 (cải thiện hiệu năng 33%), và lợi ích này dự kiến sẽ lan tới toàn hệ sinh thái như Node.js, trình duyệt Chrome và Deno
Vấn đề hiệu năng hàm lượng giác trong Node.js
- Tách biệt với benchmark của Theo, một benchmark lặp gọi các hàm lượng giác như sin, cos cho thấy Cloudflare Workers nhanh hơn 3 lần
- Nguyên nhân là Node.js chưa kịp áp dụng đường thực thi hàm lượng giác mới/tốc độ cao do V8 cung cấp (thông qua compile-time flag)
- Cloudflare Workers tình cờ bật cờ này theo mặc định, còn với Node.js thì đã có Pull Request vá lỗi được gửi lên
- Vì đây cũng là vấn đề chung của hệ sinh thái mã nguồn mở, khi được phản ánh vào AWS Lambda và Vercel thì có thể kỳ vọng tốc độ tổng thể sẽ ổn định hơn
Giới hạn và bài học trong thiết kế/đo lường benchmark
- Phần lớn benchmark đo thời gian request (latency) từ phía client, chứ không trực tiếp đo thời gian sử dụng CPU thực tế ở phía máy chủ
- Nhiều biến số không thể so sánh trực tiếp như đường đi mạng, vị trí trung tâm dữ liệu, thế hệ phần cứng và multi-tenancy có thể ảnh hưởng đến kết quả
- Nếu chỉ đo thời gian tới byte đầu tiên của phản hồi (TTFB), sẽ khó phản ánh toàn bộ thời gian render/truyền dữ liệu. Nếu chuyển sang TTFL thì lại có thể nhạy hơn với khác biệt tốc độ mạng
- Sự đa dạng về phần cứng/phần mềm máy chủ, cũng như yếu tố may rủi trong việc phân bổ instance, cũng tạo ra nhiễu tạm thời hoặc có tương quan
- Quá trình làm rõ môi trường benchmark và quy trình công việc, đồng thời căn chỉnh các biến số, đã giúp rút ra các điểm cải thiện hữu ích cho cả nền tảng của chính họ lẫn bên khác
Các vấn đề benchmark và cấu hình môi trường được phát hiện trong quá trình thử nghiệm
- Các khác biệt như force-dynamic của Next.js không được áp dụng, logic xử lý cache và cách streaming phản hồi khác nhau đã tạo ra nguy cơ hiểu sai kết quả
- Trong benchmark React SSR, biến môi trường
NODE_ENV không được thiết lập khiến hệ thống chạy ở dev mode và trả về kết quả chậm hơn thực tế
- Các lỗi này đã được sửa bằng cách thiết lập biến môi trường một cách tường minh
Kế hoạch sắp tới và kết luận
- Nhiều cải tiến hiệu năng của Cloudflare Workers Runtime đã được áp dụng trên diện rộng, nên người dùng được hưởng lợi mà không cần thao tác thêm
- Cloudflare đã cung cấp cho Theo Pull Request phản ánh mã thử nghiệm và các tối ưu hóa của OpenNext
- Dự kiến sẽ có thêm cải tiến để thu hẹp khoảng cách giữa OpenNext và Next.js chạy trên nền Vercel
- Cloudflare sẽ tiếp tục nâng cấp thuật toán lập lịch và các động cơ mã nguồn mở như V8, Node.js, đồng thời đóng góp cho cộng đồng
- Họ cũng dự định tiếp tục duy trì văn hóa phát hiện sớm vấn đề tiềm ẩn, tối ưu hóa và chia sẻ thông qua benchmark và profiling tốt hơn
Tài liệu tham khảo và liên kết bổ sung
1 bình luận
Ý kiến trên Hacker News
Việc CF thực sự nỗ lực cải thiện sản phẩm là điều đáng mừng. Tuy nhiên, thay đổi diễn ra quá nhanh nên khó theo kịp, và nhiều khi việc phát hành đi trước độ hoàn thiện. Ví dụ, R2 Data Catalog vẫn còn thiếu hỗ trợ Iceberg v3, Wrangler cũng đã thay đổi rất nhiều chỉ trong vài tháng, còn Pages thì có vẻ sắp biến mất nên việc di chuyển sang Workers Assets cực kỳ phiền phức. Cấu hình từng hoạt động tốt ở Wrangler 3 lại không được áp dụng đúng trong Wrangler 4, và có cảm giác đến Wrangler 5 sẽ lại xuất hiện một mô hình tương tác mới
Về nhận định rằng "Pages có vẻ sắp biến mất", thực tế CF đã nói trong một bài đăng cộng đồng rằng họ sẽ không loại bỏ Pages cho đến khi Workers đạt được mức độ tương đương với Pages Bài đăng liên quan Rất khó tìm thấy nội dung chính thức nào nói rằng Pages sẽ bị khai tử, và cả pages.cloudflare.com lẫn developer.cloudflare.com/pages đều vẫn đang được vận hành tích cực. Một bài đăng trên Reddit có ngụ ý về việc di chuyển khỏi Pages, nhưng ngay cả ở liên kết đó cũng không có đề cập chính thức nào về việc ngừng hỗ trợ Tôi đồng ý với các ý kiến còn lại, và đặc biệt cũng đã ngạc nhiên vì điểm đó Liên kết tham khảo trên Reddit
Tôi không đồng ý với nhận định rằng cấu hình của Wrangler 3 không còn hoạt động nguyên vẹn trong Wrangler 4. Định dạng cấu hình trong Wrangler 4 không hề thay đổi, và lý do tăng major version không ảnh hưởng đến 99,99% người dùng. Có thể xem thay đổi liên quan tại đây. Chỉ riêng việc tăng major version cũng đã gây ra nhiều bất tiện nên bản thân tôi cũng từng nêu ý kiến phản đối, nhưng đội ngũ đã rất thận trọng vì một số trường hợp ngoại lệ cực hiếm. Trong tương lai, chúng tôi sẽ phát triển cách quản lý các vấn đề kiểu này mà không cần tăng major version nữa, ví dụ như hỗ trợ song song nhiều phiên bản esbuild. Về phía runtime, chúng tôi đặc biệt chú trọng đến khả năng tương thích ngược Blog về tương thích ngược Pages không biến mất, còn Workers Assets là phiên bản triển khai linh hoạt hơn của Pages. Nếu không cần các tính năng bổ sung thì không nhất thiết phải chuyển sang, và sau này cũng sẽ có di chuyển tự động
Điều này lại nhắc tôi rằng khi xây dựng các dự án quan trọng hoặc hệ thống cần duy trì trong nhiều năm, tốt nhất nên dùng "công nghệ nhàm chán" (boring tech)
Tôi tò mò không biết bạn đã thấy cơ sở nào cho nhận định rằng "Pages có vẻ sắp biến mất". Cá nhân tôi vẫn đang dùng Pages rất tốt cho nhiều dự án
Điều thú vị là tranh cãi này bắt đầu từ tuyên bố rằng Cloudflare nhanh hơn Vercel. Sau đó có một người thật sự hiểu rõ đã tiến hành benchmark và kết quả thực tế lại cho thấy điều ngược lại, từ đó Cloudflare bắt tay vào cải thiện hiệu năng thật sự
Tôi rất thích thái độ của bài viết khi không công kích đối thủ mà tập trung tìm ra và nhấn mạnh những điểm cần cải thiện. Việc triển khai OpenNext cũng có tiến bộ, và điều đó có thể được các nhà cung cấp khác tái sử dụng, khá ấn tượng
Tôi đang chuyển từ việc host NextJS trên Vercel sang Astro/React trên Cloudflare. Điều đáng ngạc nhiên là ngay cả khi render web app ở “edge” cho mọi request, thời gian phản hồi vẫn chỉ khoảng 100-200ms, nhanh gần như không thua gì trang tĩnh. Trong vài tuần gần đây, tôi cũng cảm nhận rất rõ các cải thiện ở Cloudflare Worker: cold start gần như biến mất và tốc độ phản hồi ổn định hơn nhiều Liên kết web app đang port
Thật thú vị khi một video do một YouTuber không quá nổi tiếng đăng tải lại có thể lan truyền hiệu quả theo cách này, và dẫn đến những cải thiện thực sự có ý nghĩa cùng việc xử lý các vấn đề nền tảng từ phía Cloudflare
Đây là một màn PR được thực hiện quá tốt. Xin gửi lời khen tới những người đã chuẩn bị bài đăng này
Với tư cách là khách hàng cf lâu năm, tôi có thể nói rằng cf không chỉ viết blog hay và làm mã nguồn mở tốt mà còn là công ty hạ tầng có hỗ trợ dịch vụ tốt nhất. Các thành viên trong nhóm, bao gồm cả kenton, thường trực tiếp giúp người dùng trên Discord hoặc tiếp nhận phản hồi, và với bug hay issue thì thường có thể trao đổi ngay với kỹ sư phụ trách thực tế. Thậm chí những PR hoặc yêu cầu tính năng do tôi đề xuất cũng từng được phản hồi rất nhanh mà không cần thủ tục rườm rà. Với mức giá rẻ hơn rất nhiều so với các công ty lớn khác, tôi lại nhận được hỗ trợ tốt hơn hẳn
Cảm ơn! PR và bài đăng này được chính các kỹ sư trong nhóm Workers chủ động lên kế hoạch và thực hiện 100% (tôi cũng tham gia)
Tôi rất thích cách bài đăng này được viết, cách phân tách thông tin và cả việc thảo luận công khai. Mức độ tin tưởng của tôi với nhóm Cloudflare workers đã tăng lên
Theo tôi thì SvelteKit cực kỳ nhanh, còn Next.js thì tương đối rất chậm
Kết luận nghe khá hợp lý
Tôi hy vọng những framework thực dụng như SvelteKit, Astro và TanStack sẽ sớm thay thế sự phức tạp của NextJS
Đây chính là lý do cần có cạnh tranh và benchmark độc lập. Nó buộc cả những dịch vụ còn thiếu hiệu năng cũng phải nỗ lực cải thiện
Nhưng nỗ lực đó cũng chỉ hiệu quả khi họ thực sự quan tâm đến sản phẩm
Benchmark độc lập thực ra đã tồn tại rồi
Tôi ấn tượng với cách Cloudflare khiêm tốn chấp nhận kết quả và cải thiện một cách mang tính xây dựng
Đây là một bài viết hay, tập trung vào nội dung và không đổ lỗi. Nhưng tôi vẫn khá ngạc nhiên là trước đây Cloudflare dường như chưa giám sát và điều chỉnh trước tốt hơn những thứ như kích thước generation. Trong kinh nghiệm tuning hiệu năng JVM của tôi, việc thiết lập generation size là điều rất cơ bản