Misskey (GeekNews) là một chương trình máy chủ microblogging hỗ trợ liên hợp ActivityPub. Misskey chủ yếu được phát triển tại Nhật Bản, và là một nền tảng được nhiều người dùng tìm đến để tìm kiếm sự thú vị nhờ có rất nhiều tính năng vui nhộn như phản ứng bằng emoji, MFM là ngôn ngữ đánh dấu riêng, theo dõi từ khóa (ăng-ten), trang trí hồ sơ, tạo trang tương tác bằng AiScript là ngôn ngữ script riêng, mini-game, v.v.
Theo những gì tôi biết, stack kỹ thuật của Misskey như sau. (Có thể không chính xác.)
- NodeJS, TypeScript
- Koa.js, PostgreSQL, Redis
- Vue
Trong bài viết này, syuilo, người bảo trì chính của Misskey, kiểm chứng hiệu năng của Bun khi so sánh với NodeJS bằng chính mã nguồn của Misskey.
- Mục đích là kiểm tra xem khi chạy nguyên trạng mã nguồn hiện có bằng Bun thì có nhanh hơn hay không. Bài viết cho biết không thực hiện tối ưu hóa riêng cho Bun, và nếu phần mã không tương thích quá phức tạp thì sẽ không tiến hành thử nghiệm.
- Bài viết cũng lưu ý rằng đây chỉ nên được xem như một trường hợp tham khảo.
- Thử nghiệm được thực hiện trên Ubuntu, nhưng theo bài viết thì trên Windows cũng không có khác biệt lớn.
Nói thẳng kết luận trước thì, trong trường hợp này, hiện tượng chủ yếu là hiệu năng trên Bun lại bị giảm. Có vẻ kết luận là không thể nói rằng chỉ cần chạy một codebase lớn hiện có bằng Bun thì sẽ magically nhanh hơn. Nội dung do ChatGPT tóm tắt là như sau.
- Mức sử dụng bộ nhớ: Node khoảng 200MB, Bun khoảng 800MB, Bun tiêu tốn bộ nhớ nhiều hơn rất nhiều.
- Tốc độ thực thi: Trong nhiều tác vụ như truy vấn timeline, Node ghi nhận kết quả nhanh hơn. Đặc biệt, khi đăng bài, Node mất 5 giây còn Bun mất 10 giây, tức Node nhanh gấp 2 lần.
- AiScript: Khi chạy mã JavaScript thuần, Node (động cơ V8) nhanh hơn khoảng 1,5 lần.
Bài viết có đăng benchmark thực thi của từng phần trong codebase, nhưng ngoại trừ lần chạy một lần duy nhất của WebSocket thì tất cả đều cho thấy NodeJS nhanh hơn, hoặc là chênh lệch nhỏ hoặc là chênh lệch đáng kể. Ngay cả trong trường hợp chạy WebSocket, khi thực thi 100.000 lần thì NodeJS cũng cho kết quả nhanh hơn một chút.
Tuy vậy, tác giả bài viết là syuilo vẫn kỳ vọng vào tiềm năng phát triển của Bun, đồng thời cũng nhắc đến khả năng hiệu năng có thể được cải thiện thêm qua tối ưu hóa bổ sung.
9 bình luận
Trong trường hợp chỉ đổi đơn giản rồi chạy, vẫn có những ca chưa được tối ưu đầy đủ như các thư viện liên quan đến
node:cryptohayzlib, điều này cũng đã được ghi rõ trong tài liệu và issue của Bun.Nếu trong ví dụ mà chậm đi đến mức từ 5 giây thành 10 giây thì có lẽ là rơi vào kiểu trường hợp này. Thực tế tôi cũng từng bị chậm hơn vài lần vì vấn đề này ở một thư viện liên quan đến JWT, nên cuối cùng phải đổi thư viện và tối ưu lại.
Tôi tò mò không biết bạn lấy các bài viết blog kỹ thuật bằng tiếng Nhật từ đâu. Chúng có cảm giác rất hệ thống và nêu được đúng các ý cốt lõi.
Tôi không rõ các bài khác thế nào, nhưng bài này được đăng lên Misskey nên có thể xem từ Fediverse (tôi cũng thấy ở đó trước rồi mới thấy nó được đăng lên đây).
Tôi không rõ nguồn của phần nội dung này, nhưng có vẻ trên Qiita có khá nhiều bài viết hay. Có những người dịch và đăng lại các bài phân tích với góc nhìn khác với blog ở khối Anh ngữ hay Hàn Quốc trên nhiều kênh, và điểm chung là phần lớn đều là bản dịch từ các bài viết trên Qiita.
Nhờ gợi ý trong tự động hoàn thành của Google Tìm kiếm so sánh kita và zenn, tôi cũng đã tìm được zenn. Xin cảm ơn vì thông tin này.
Qiita được đọc là Kì-ta.
À, ra là vậy, ngại quá.
Đây là một kết quả cực kỳ thú vị. Với Bun, ElysiaJS thường được khuyến nghị nhiều làm web framework, nhưng nếu không dùng API được Bun cung cấp và tối ưu hóa thì lại có vấn đề là hiệu năng thậm chí còn giảm. Bài viết cho biết họ đã dùng Koa.js, nên có thể suy đoán rằng hiệu năng đã giảm khá nhiều ở phía đó.
Có lẽ cần phân biệt giữa sự khác nhau của runtime và mức độ tích hợp với hệ thống.
Hiệu năng mà Bun tự hào nhìn chung đến từ đặc tính của JSC, cùng với việc tối ưu hóa một phần tích hợp hệ thống (hoặc cắt giảm tính năng) và lựa chọn các thư viện nền tảng tốt.
Vì vậy, trong các benchmark quy mô nhỏ thì Bun có xu hướng thắng, nhưng đồng thời ở các benchmark quy mô lớn/chạy dài hạn thì lại có xu hướng thua Node.js.