Kết luận chính
- Ngôn ngữ Go không phải lúc nào cũng nhanh. Thậm chí runtime JS còn có thể nhanh hơn.
- Go nổi tiếng với sự đơn giản và hiệu quả, nhưng trong môi trường thực tế, đôi khi hiệu năng lại thấp hơn kỳ vọng.
- Đặc biệt, trong các tình huống có nhiều database I/O, hiệu năng có thể kém hơn so với các runtime JavaScript như Bun.
Kết quả benchmark
- Go cho thấy thông lượng xử lý request cao hơn và mức sử dụng bộ nhớ thấp hơn, nhưng mức sử dụng CPU lại cao hơn 2~3 lần.
- Tuy nhiên, trong môi trường thực tế có nhiều DB I/O, Bun (kết hợp framework Elysia và thư viện MySQL2) cho hiệu năng ổn định và hiệu quả hơn.
- HTTP router tiêu chuẩn có hiệu năng thấp, và sau khi chuyển sang framework Fiber, đã đạt được tốc độ phản hồi tương tự Bun. (Đừng dùng Go standard HTTP Router!)
Những ưu điểm của Go khi thực hiện benchmark này
- Cung cấp nhiều kiểu dữ liệu nguyên thủy và tính an toàn kiểu.
- Triển khai single binary: có thể phát hành dưới dạng file thực thi đơn giản, loại bỏ phụ thuộc vào runtime.
- Goroutine: hỗ trợ xử lý song song hiệu quả, nếu dùng đúng cách có thể khai thác tối đa hiệu năng phần cứng.
Những giới hạn và dư địa cải thiện rút ra từ benchmark lần này
- Nghi ngờ có vấn đề về hiệu năng của MySQL driver:
go-mysql-driver của Go ổn định nhưng chậm, và có vẻ kém hơn mysql2 của JavaScript về hiệu năng. (Tất nhiên cũng có thể là do tôi nghĩ sai)
- Với các tác vụ không có kết nối DB, Go cho hiệu năng tốt hơn. Có lẽ điều này cũng là hiển nhiên.
- Hiệu năng thấp của HTTP router: vì sức khỏe tinh thần của bạn, hãy dùng Fiber hoặc framework khác!
Lý do vẫn muốn tiếp tục dùng Go dù chưa hài lòng về hiệu năng
- Tính an toàn kiểu của Go, khả năng triển khai single binary, và hiệu năng xử lý song song của goroutine đều rất hấp dẫn với tư cách là lập trình viên. Những kiểu dữ liệu mà TypeScript không thể thay thế, cùng việc triển khai file single binary không cần
npm install, thực sự là lợi thế rất lớn.
- Nhìn thấy thêm khả năng tối ưu hiệu năng, nên tôi quyết định sẽ tiếp tục học và sử dụng Go nhiều hơn.
Gửi tới các lập trình viên
- Mọi ngôn ngữ và công nghệ đều có ưu và nhược điểm. Tôi nghĩ Go cũng vậy.
- Thay vì thất vọng về hiệu năng của Go, sẽ tốt hơn nếu tận dụng tốt các ưu điểm của nó và tiếp tục tìm cách vượt qua giới hạn hiệu năng.
- Tôi viết bài này để chia sẻ với các lập trình viên đang dùng Go rằng cũng có những kết quả phân tích như thế này.
16 bình luận
Hơi lạc đề một chút, nhưng font IBM Plex Sans KR đẹp quá.
Tôi cũng rất thích phông chữ đó nên đã dùng, nhưng chỉ có đúng một điểm hơi tiếc là khi nhìn trên màn hình độ phân giải thấp thì nó lại không đẹp nổi bật như vậy. Haha, còn khi xem trên màn hình 5K thì thật sự rất đẹp!
Tôi nghĩ rằng việc chỉ trích điều gì đó thật sự cần phải hết sức thận trọng.
Trong khi còn chưa rõ đó là vấn đề ở cấp độ ngôn ngữ, vấn đề của một thư viện cụ thể hay vấn đề trong mã nguồn, và cũng chưa cung cấp đủ thông tin để người khác có thể tái hiện, thì việc công khai khẳng định rằng một thứ gì đó là không tốt
cho dù không có chủ ý như vậy đi nữa, có lẽ cũng không phải là nội dung khiến những người đang sống trong hệ sinh thái đó cảm thấy dễ chịu.
Xin chào! Trước hết, xin cảm ơn bạn đã để lại ý kiến quý báu. Tôi hiểu bạn đã viết bình luận đó với tâm thế như thế nào về những điều bạn nói, và nếu lỡ như bài viết khiến bạn cảm thấy như tôi đang chỉ trích tương lai của ngôn ngữ Go hay những người dùng nó, thì tôi xin được một lần nữa nói rõ rằng hoàn toàn không phải vậy, đồng thời cũng xin gửi lời xin lỗi. Ngoài ra, nếu bạn thấy ổn, khi bấm vào tiêu đề bài viết bạn sẽ thấy nhiều dữ liệu cùng thêm cả bài blog của một người khác, nên tôi nghĩ nếu bạn đọc qua (dù hơi dài một chút) thì sẽ hiểu rõ hơn ý định của tôi.
Tôi thường nghĩ ngôn ngữ cũng giống như một loại ô tô. Mỗi chiếc xe đều có nhiều ưu và nhược điểm, chi phí sở hữu cũng khác nhau, và dù có vẻ cùng đảm nhiệm một vai trò thì lại theo đuổi những giá trị khác nhau — ở điểm này chúng khá giống nhau. Tất nhiên, tôi cũng cho rằng việc dành tình cảm đặc biệt và yêu quý một mẫu xe nào đó là điều hoàn toàn tự nhiên. Bản thân tôi cũng yêu chiếc xe của mình và tin tưởng hãng sản xuất của nó.
Dù vậy, tôi cũng có những điểm thấy tiếc hoặc chưa hài lòng về chiếc xe của mình, và các reviewer chuyên đánh giá xe theo định kỳ vẫn luôn chia sẻ nội dung bằng cách so sánh với các mẫu cạnh tranh trên nhiều phương diện. Nếu ai đó nói hộp số của xe tôi không tốt lắm, hay mức tiêu hao nhiên liệu kém, thì thật lòng tôi cũng không thấy vui. Nhưng dù vậy, tôi vẫn cố gắng tách biệt giữa bản thân người lái là tôi và chiếc xe. Đồng thời, tôi cũng cố gắng tìm hiểu nhiều hơn về cả ưu điểm lẫn nhược điểm của chiếc xe mình đang lái. Biết đâu sau này tôi sẽ lái một chiếc xe khác, nhưng trải nghiệm lái xe hiện tại chắc chắn khi đó vẫn sẽ hữu ích.
Trong bản tóm tắt tôi không nhắc được nhiều, nhưng ở phần thân bài blog, tôi đã kết lại bằng ý rằng dù Go có những điểm còn đáng tiếc, nó vẫn có nhiều ưu điểm hơn nên tôi định sẽ tiếp tục sử dụng (= lái) nó. Tôi nghĩ mỗi ngôn ngữ đều theo đuổi những giá trị và thế mạnh khác nhau, vì vậy tôi thuộc kiểu luôn cố gắng dùng thử nhiều ngôn ngữ (= nhiều loại xe) nhất có thể. Đó cũng là lý do tôi lại muốn chuyển từ JS runtime vốn đang dùng tốt sang ngôn ngữ Go.
Tôi đã nghĩ rằng mình đã viết bài khá cẩn thận theo cách riêng để tránh tối đa những cuộc tranh cãi ngôn ngữ không cần thiết, nhưng dù vậy, nếu vẫn có những Gopher cảm thấy không vui khi đọc bài này, thì tôi mong các bạn có thể nguôi giận một lần nữa. Và xin được khép lại bình luận bằng việc nói rằng tôi là một coder lãng mạn, đến cả ngôn ngữ PHP từng bị chê bai nhiều đến thế mà tôi cũng vẫn yêu mến!
Trong bài gốc có ghi phân tích riêng của tác giả về những phần chậm, và cả lý do vì sao dù vậy vẫn sẽ dùng Go, nên tôi không hiểu lắm vì lý do gì mà bạn lại tiếp nhận bài viết này như một sự phán xét giá trị.
Hơi là TMI nhưng thư viện
stdcủa Go đang dần giảm hiệu năng theo thời gian. Lý do chính là sự đánh đổi với vô số lỗ hổng bảo mật được báo cáo khi nhiều tính năng được bổ sung để tuân thủ tiêu chuẩn RFC.Gần đây, để vượt qua chứng nhận FIPS, có lẽ mức tổn thất về hiệu năng sẽ còn tăng thêm.
Nếu bỏ qua toàn bộ những bối cảnh này và chỉ viết đúng một câu rằng hiệu năng kém trong một kịch bản cụ thể đơn giản nhất, thì theo tôi điều đó hoàn toàn đủ để khiến nhiều người hiểu lầm T_T
Tôi đang chờ phiên bản 1.0 của tsboard haha
Cảm ơn bạn đã chờ đợi! Mình sẽ vui vẻ bắt tay vào thực hiện đây haha
Tôi nghĩ vì JS dùng JIT nên cũng không có lý do gì để nó đặc biệt chậm cả.
Nếu bỏ qua đa luồng, độ ổn định v.v..
Điều tôi mới phát hiện(?) qua lần benchmark này là, mức độ ổn định cũng không đến mức có vấn đề lớn nên tôi nghĩ mình có thể mạnh dạn nói như vậy. Đa luồng thì rõ ràng vẫn cần orchestration (không biết dùng từ này có đúng không nữa), nên đúng là hơi bất tiện.
Tôi không vào được trang web, có phải chỉ mình tôi bị vậy không?
Xin chào! Cảm ơn bạn đã cho biết qua phần bình luận haha, hiện mình vẫn chưa chuyển được trang sang hosting nên thỉnh thoảng có thể xảy ra sự cố truy cập! Mình sẽ cố gắng xử lý trong thời gian sớm nhất có thể. (Hiện tại chiếc mini PC ở nhà đang cày hết công suất 😂)
Ồ, giờ thì được rồi. Tôi sẽ đọc kỹ!
Tôi đã chuyển trang web từ một mini PC đặt trong phòng sang một máy chủ ảo có quy mô cỡ một căn phòng đơn...! Hôm nay, đã có nhiều người ghé thăm hơn dự kiến rồi phải quay về giữa chừng, nhưng giờ tôi xin thông báo rằng sẽ không còn vấn đề gì nữa!
Tôi khá tò mò liệu khi thử nghiệm với driver
github.com/jackc/pgx/v5và PostgreSQL thì kết quả có khác đi không.Tôi cũng rất tò mò liệu kết quả này chỉ giới hạn ở MySQL hay áp dụng cho mọi kịch bản sử dụng DB. Tôi nghĩ rồi sẽ có lúc những người khác chia sẻ kết quả thôi haha