Hi all, Em đã test lại trên golang (window). Kết quả như sau: 10tr task, mỗi task đợi 10s, tốn 19,1GB và mất 44.4s hoàn thành 10tr task, mỗi task đợi 1s tốn 13.9GB và mất 11.5s hoàn thành 10tr task, mỗi task không đợi thì tốn 20MB và mất 3.2s hoàn thành 100tr task, mỗi task không đợi, cũng chỉ tốn 20MB nhưng tốn 35s hoàn thành => Ta thấy Go rất tốn bộ nhớ với các tác vụ phải chờ hoàn thành lâu, sở dĩ như vậy vì cơ chế concurency với goroutines (GRT) sẽ giữ tất cả GRT trong bộ nhớ và chờ đến khi được gọi. Go runtime không giải phóng bất cứ GRT nào mà nạp tất cả cùng lúc vào Heap, để khi tất cả cùng đợi xong thì tất cả cũng sẽ được sử lý cùng lúc. Chính vì vậy nếu trong dự án thực tế, nếu chúng ta có nhiều scheduler với thời gian chờ mỗi cái lâu thì Go có vẻ không thích hợp. Ngược lại với Nodejs, kết quả test khác biệt rõ rệt: 1tr task, mỗi task đợi 10s, bộ nhớ tiêu tốn rất ít, chỉ tầm 200-300MB, đúng như video chia sẻ, và quan trọng là thời gian hoàn thành 1tr task đó chỉ tốn 10,7s. Tức là hơn Go về mọi mặt, cả về hiệu năng RAM và tổng thời gian hoàn thành. Tuy nhiên có 1 nhược điểm là Promise.All không xử lý được quá nhiều task đồng thời. Dường như 1tr task cùng lúc là giới hạn của nó. Thử lên 2tr task là không chạy được nữa. Thế nhưng riêng với backend, trước đó em đã thử nghiệm thực tế khả năng chịu tải của các ngôn ngữ với việc tạo các server tối giản nhất và đo benchmark, kết quả như sau: Vanilla Nodejs: 120k req/s ExpressJs: 62k req/s, càng dùng nhiều Midleware càng tụt sâu Fastify (framework nodejs nhanh nhất theo quảng cáo): 120k req/s, gần như tương đồng với việc code thuần. Cả 3 tiêu tốn bộ nhớ không quá nhiều, chỉ tầm 2-3GB, CPU lên tầm 60-70% Vanilla Golang: 440k req/s (shock nặng) Tiêu tốn bộ nhớ không nhiều, cũng chỉ tầm 2-3GB, CPU cũng cực ít, chỉ tầm 20% ASP..NET 7 : 240kreq/s nhưng tốn rất nhiều CPU, gần như full load, RAM ngốn cũng tầm 3GB Có thể thấy Golang chịu tải rất cao và tiêu tốn vô cùng ít tài nguyên, nhưng với thử nghiệm hôm nay, em sẽ nghĩ đến việc sử dụng kết hợp Nodejs và Go, trong đó Go xử lý chính các request, còn Node sẽ xử lý các tác vụ tốn nhiều thời gian chờ như scheduler. Đây có lẽ là 2 lựa chọn hợp lý với các cty nhỏ vì tiết kiệm được nhiều tiền thuê server. Còn với các doanh nghiệp lớn thì cứ ổn định an toàn là trên hết, chậm và tốn tài nguyên hơn chút cũng không sao nên Java và .NET vẫn sẽ muôn đợi thịnh.
Sau khi đọc bài viết xong mới thấy người viết bài không hiểu về mutil-thread và như bạn @vanvothe4817 đã viết: "async trong node và go/rust/java rất khác nhau về mặt bản chất". Dẫn đến kết quả test không hề đáng tin cậy. 1. Ví dụ đưa ra quá đơn giản là tạo 1 thead -> sleep. Chẳng hề có tính toán hay cấp phát bộ nhớ cho biến để từ đó thấy được mức độ tiêu thụ bộ nhớ. Bài test chỉ đang cố nói lên việc khởi tạo 1000.000 thread/async khác nhau như nào trong các ngôn ngữ. Thực tế còn phải xem xét ở các khía cạnh khác: cấp phát, thu hồi và mức độ tiêu thụ trong 1 khoảng thời gian. 2. Trong thực tế chẳng ai đi spam số lượng thread/async = số lượng task cả. Vì còn phải tính tới yếu tố là CPU nữa. Đâu phải cứ cố gắng tạo ra thật nhiều async/thread thì sẽ tốt hơn. ==> Bài viết đọc cho vui chứ không nói nên điều gì khi áp vào thực tế
Mong a ra một video về code giải thích về cơ chế upload file nặng với nodejs. Em đang lấn không biết xử lý upload file nặng với nestjs. Em có gg thì có cách là dùng stream nhưng chưa biết xử lý như nào. Hy vọng được a rep ạ.
Bác có thể tham khảo thêm native image built từ Gralvvm tool của Oracle, các framework sử dụng là springboot hoặc quarkus. Rất nhẹ và tiêu tốn ít ram, bù lại build time khá lâu.
Sau khi build xong thì nhìn chung RAM của java sẽ tương đương với Golang. Với kiểu test của video thì apply JDK 21 + build GraalVM chắc kèo Mem Java sẽ ít hơn Mem Golang => Java vẫn là cái gì đó rất toàn diện có điều ở VN thì build java native ít phổ biến.
@@phamthehung6214 java community nó dịch chuyển chậm vì code base quá ổn định rồi. Vấn đề của java và ecosytem là tài nguyên server/cloud dành cho jvm khá lớn, dẫn đến tốn tiền quá. Với tốc độ phát triển như hiện h thì việc các cty thế giới nâng cấp lên java 17 có thể sẽ nhanh hơn giai đoạn từ java8 -> java11 => mấy vụ build source native sẽ nhiều hơn => đỡ tốn tiền hơn.
Gì mà Framework ghê vậy. Framework nó ko đơn giản đâu. Với những tính năng cơ bản và nâng cao thì socket chỉ có mục đích gửi và nhận dữ liệu thôi. Có chăng đó là library :D
@@phongthai1505 Mình viết cho server game nên cần hiệu năng cao nhưng vẫn muốn nó thân thiện với các webdev nên concept mình học hỏi từ spring và dotnet. Về cách sử dụng phải nói là tương đồng với 2 framework trên nhưng có hiệu năng rất tuyệt vời(tất nhiên là phải có đánh đổi). Khác với các lib socket game khác là mình sẽ có quy ước gói tin (protocol riêng), có lựa chọn thread safe hay đa luồng, có các plugin lib để tùy biến nhu cầu sử dụng. Nói chung có thể gọi nó là framework vì developer sẽ theo rule của mình và các vấn đề ở tầng low code không cần quan tâm.
@@thangchiba chào bác, bác cho e hỏi bác viết server game trên C# có sử dụng thư viện nào không? e không theo lập trình server game nhưng vẫn rất tò mò vụ này.
@@HaiNguyen-fu6sd mình viết từ đầu socket solution riêng nên hầu như các lib chỉ tham khảo concept và clone ra 1 cái tương tự để xài. Ví dụ event loop như libuv, storage như redis.
Benchmark chỉ nên tham khảo vì async trong node và go/rust/java rất khác nhau về mặt bản chất, chưa kể là việc tác giả sử dụng chatgpt tạo ra code mà không có kiến thức về ngôn ngữ hay tham vấn là một sai lầm, riêng rust thì không có gì bàn cãi nhưng trường hợp với go sự khác biệt giữa 100.000 và 1.000.000 quá chênh lệch phải có điều gì đó không đúng trong trường hợp này?
Code go có 10 dòng như này thì cũng chẳng có gì nhiều để optimize cả var wg sync.WaitGroup for i := 0; i < numRoutines; i++ { wg.Add(1) go func() { defer wg.Done() time.Sleep(10 * time.Second) }() } wg.Wait()
@@vanvothe4817 Đúng là rust thì khoai vụ viết code hơn dù perf hay mem tối ưu rất tốt, nhưng viết khá mệt, đúng là chỉ dành cho viết cái gì đó quy mô, như vụ discord phải bỏ go sang rust vì cái GC cũng là usecase phù hợp với hoàn cảnh Mà go thì dễ viết hơn nhiều dù perf có thể kém rust nhưng mà có vẻ cũng k quá quan trọng lắm vì cũng phải đặt vào ngữ cảnh cụ thể nào đó như trên để chọn cho phù hợp nhỉ
@@NguyenMinh-gl7qz thì rõ quá rồi b, go là ngôn ngữ lập trình ứng dụng nên phải cân bằng giữa hiệu suất và tốc độc phát triển ứng dụng (tốc độ viết code), độ thân thiện với coder, còn rust là ngôn ngữ lập trình hệ thống nên hiệu suất và độ an toàn bộ nhớ luôn phải ưu tiên tập trung phát triển hàng đầu nên rust nó mới quái vật như thế 🙂 đổi lại thì nó yêu cầu coder phải tuân thủ nghiêm ngặt các quy tắc khi viết code nên sẽ khó khăn hơn vs tốc độ phát triển ứng dụng sẽ chậm hơn, thời gian để compile code cũng chậm hơn
Hi all,
Em đã test lại trên golang (window). Kết quả như sau:
10tr task, mỗi task đợi 10s, tốn 19,1GB và mất 44.4s hoàn thành
10tr task, mỗi task đợi 1s tốn 13.9GB và mất 11.5s hoàn thành
10tr task, mỗi task không đợi thì tốn 20MB và mất 3.2s hoàn thành
100tr task, mỗi task không đợi, cũng chỉ tốn 20MB nhưng tốn 35s hoàn thành
=> Ta thấy Go rất tốn bộ nhớ với các tác vụ phải chờ hoàn thành lâu, sở dĩ như vậy vì cơ chế concurency với goroutines (GRT) sẽ giữ tất cả GRT trong bộ nhớ và chờ đến khi được gọi. Go runtime không giải phóng bất cứ GRT nào mà nạp tất cả cùng lúc vào Heap, để khi tất cả cùng đợi xong thì tất cả cũng sẽ được sử lý cùng lúc.
Chính vì vậy nếu trong dự án thực tế, nếu chúng ta có nhiều scheduler với thời gian chờ mỗi cái lâu thì Go có vẻ không thích hợp.
Ngược lại với Nodejs, kết quả test khác biệt rõ rệt:
1tr task, mỗi task đợi 10s, bộ nhớ tiêu tốn rất ít, chỉ tầm 200-300MB, đúng như video chia sẻ, và quan trọng là thời gian hoàn thành 1tr task đó chỉ tốn 10,7s. Tức là hơn Go về mọi mặt, cả về hiệu năng RAM và tổng thời gian hoàn thành.
Tuy nhiên có 1 nhược điểm là Promise.All không xử lý được quá nhiều task đồng thời. Dường như 1tr task cùng lúc là giới hạn của nó. Thử lên 2tr task là không chạy được nữa.
Thế nhưng riêng với backend, trước đó em đã thử nghiệm thực tế khả năng chịu tải của các ngôn ngữ với việc tạo các server tối giản nhất và đo benchmark, kết quả như sau:
Vanilla Nodejs: 120k req/s
ExpressJs: 62k req/s, càng dùng nhiều Midleware càng tụt sâu
Fastify (framework nodejs nhanh nhất theo quảng cáo): 120k req/s, gần như tương đồng với việc code thuần.
Cả 3 tiêu tốn bộ nhớ không quá nhiều, chỉ tầm 2-3GB, CPU lên tầm 60-70%
Vanilla Golang: 440k req/s (shock nặng)
Tiêu tốn bộ nhớ không nhiều, cũng chỉ tầm 2-3GB, CPU cũng cực ít, chỉ tầm 20%
ASP..NET 7 : 240kreq/s nhưng tốn rất nhiều CPU, gần như full load, RAM ngốn cũng tầm 3GB
Có thể thấy Golang chịu tải rất cao và tiêu tốn vô cùng ít tài nguyên, nhưng với thử nghiệm hôm nay, em sẽ nghĩ đến việc sử dụng kết hợp Nodejs và Go, trong đó Go xử lý chính các request, còn Node sẽ xử lý các tác vụ tốn nhiều thời gian chờ như scheduler. Đây có lẽ là 2 lựa chọn hợp lý với các cty nhỏ vì tiết kiệm được nhiều tiền thuê server. Còn với các doanh nghiệp lớn thì cứ ổn định an toàn là trên hết, chậm và tốn tài nguyên hơn chút cũng không sao nên Java và .NET vẫn sẽ muôn đợi thịnh.
bạn test bằng tools gì vậy ?
Em tôi test lại chuẩn quá
@@NTHiep-ng7jn autocannon bạn nhé, trên kênh cũng đã có video sử dụng autocannon để test
Hay quá rất cần sự đóng góp như này của a
Sau khi đọc bài viết xong mới thấy người viết bài không hiểu về mutil-thread và như bạn @vanvothe4817 đã viết: "async trong node và go/rust/java rất khác nhau về mặt bản chất". Dẫn đến kết quả test không hề đáng tin cậy.
1. Ví dụ đưa ra quá đơn giản là tạo 1 thead -> sleep. Chẳng hề có tính toán hay cấp phát bộ nhớ cho biến để từ đó thấy được mức độ tiêu thụ bộ nhớ. Bài test chỉ đang cố nói lên việc khởi tạo 1000.000 thread/async khác nhau như nào trong các ngôn ngữ. Thực tế còn phải xem xét ở các khía cạnh khác: cấp phát, thu hồi và mức độ tiêu thụ trong 1 khoảng thời gian.
2. Trong thực tế chẳng ai đi spam số lượng thread/async = số lượng task cả. Vì còn phải tính tới yếu tố là CPU nữa. Đâu phải cứ cố gắng tạo ra thật nhiều async/thread thì sẽ tốt hơn.
==> Bài viết đọc cho vui chứ không nói nên điều gì khi áp vào thực tế
Mong a ra một video về code giải thích về cơ chế upload file nặng với nodejs. Em đang lấn không biết xử lý upload file nặng với nestjs. Em có gg thì có cách là dùng stream nhưng chưa biết xử lý như nào. Hy vọng được a rep ạ.
Tokio và async-std là hai runtime bất đồng bộ của Rust nhé ae. Hiểu nôm na như Nodejs với Deno vậy.
à, tks em...
Bác có thể tham khảo thêm native image built từ Gralvvm tool của Oracle, các framework sử dụng là springboot hoặc quarkus. Rất nhẹ và tiêu tốn ít ram, bù lại build time khá lâu.
OK em, tks em nhiều!
Sau khi build xong thì nhìn chung RAM của java sẽ tương đương với Golang. Với kiểu test của video thì apply JDK 21 + build GraalVM chắc kèo Mem Java sẽ ít hơn Mem Golang => Java vẫn là cái gì đó rất toàn diện có điều ở VN thì build java native ít phổ biến.
@@phamthehung6214 java community nó dịch chuyển chậm vì code base quá ổn định rồi. Vấn đề của java và ecosytem là tài nguyên server/cloud dành cho jvm khá lớn, dẫn đến tốn tiền quá. Với tốc độ phát triển như hiện h thì việc các cty thế giới nâng cấp lên java 17 có thể sẽ nhanh hơn giai đoạn từ java8 -> java11 => mấy vụ build source native sẽ nhiều hơn => đỡ tốn tiền hơn.
Đang dùng C# để viết socket framework. Viết rất là sướng mà hiệu năng vẫn rất đỉnh nếu tối ưu tốt.
Gì mà Framework ghê vậy.
Framework nó ko đơn giản đâu.
Với những tính năng cơ bản và nâng cao thì socket chỉ có mục đích gửi và nhận dữ liệu thôi.
Có chăng đó là library :D
@@phongthai1505 Mình viết cho server game nên cần hiệu năng cao nhưng vẫn muốn nó thân thiện với các webdev nên concept mình học hỏi từ spring và dotnet. Về cách sử dụng phải nói là tương đồng với 2 framework trên nhưng có hiệu năng rất tuyệt vời(tất nhiên là phải có đánh đổi). Khác với các lib socket game khác là mình sẽ có quy ước gói tin (protocol riêng), có lựa chọn thread safe hay đa luồng, có các plugin lib để tùy biến nhu cầu sử dụng. Nói chung có thể gọi nó là framework vì developer sẽ theo rule của mình và các vấn đề ở tầng low code không cần quan tâm.
Thấy c# giờ hay dùng signalr cho notifi . Mình cũng hay dùng.
@@thangchiba chào bác, bác cho e hỏi bác viết server game trên C# có sử dụng thư viện nào không? e không theo lập trình server game nhưng vẫn rất tò mò vụ này.
@@HaiNguyen-fu6sd mình viết từ đầu socket solution riêng nên hầu như các lib chỉ tham khảo concept và clone ra 1 cái tương tự để xài. Ví dụ event loop như libuv, storage như redis.
mọi nguoif cho em hoi cách build 1 du án có cấu trúc như kenh tipjs dduocj không ạ
Trong hội viên á em.
Benchmark chỉ nên tham khảo vì async trong node và go/rust/java rất khác nhau về mặt bản chất, chưa kể là việc tác giả sử dụng chatgpt tạo ra code mà không có kiến thức về ngôn ngữ hay tham vấn là một sai lầm, riêng rust thì không có gì bàn cãi nhưng trường hợp với go sự khác biệt giữa 100.000 và 1.000.000 quá chênh lệch phải có điều gì đó không đúng trong trường hợp này?
Code go có 10 dòng như này thì cũng chẳng có gì nhiều để optimize cả
var wg sync.WaitGroup
for i := 0; i < numRoutines; i++ {
wg.Add(1)
go func() {
defer wg.Done()
time.Sleep(10 * time.Second)
}()
}
wg.Wait()
Đồng quan điểm
code có vấn đề hoặc ko tối ưu tương đồng chứ go chỉ có thể kém rust thôi chứ nhỉ.
trời đụ thằng C# khá ngạc nhiên, mà nó chưa tính tới thời gian xử lý nhỉ
Anh ơi. Anh có khoá học nodejs ko ạ?
Em đăng ký hội viên ở link dưới phần mô tả đó em
Rust vẫn là 1 cái gì đó rất vcl =)), học nó cũng mệt vcl nữa
Cái gì cũng có đánh đổi hết, go nó rất cân bằng.
@@vanvothe4817 Đúng là rust thì khoai vụ viết code hơn dù perf hay mem tối ưu rất tốt, nhưng viết khá mệt, đúng là chỉ dành cho viết cái gì đó quy mô, như vụ discord phải bỏ go sang rust vì cái GC cũng là usecase phù hợp với hoàn cảnh
Mà go thì dễ viết hơn nhiều dù perf có thể kém rust nhưng mà có vẻ cũng k quá quan trọng lắm vì cũng phải đặt vào ngữ cảnh cụ thể nào đó như trên để chọn cho phù hợp nhỉ
@@NguyenMinh-gl7qz thì rõ quá rồi b, go là ngôn ngữ lập trình ứng dụng nên phải cân bằng giữa hiệu suất và tốc độc phát triển ứng dụng (tốc độ viết code), độ thân thiện với coder, còn rust là ngôn ngữ lập trình hệ thống nên hiệu suất và độ an toàn bộ nhớ luôn phải ưu tiên tập trung phát triển hàng đầu nên rust nó mới quái vật như thế 🙂 đổi lại thì nó yêu cầu coder phải tuân thủ nghiêm ngặt các quy tắc khi viết code nên sẽ khó khăn hơn vs tốc độ phát triển ứng dụng sẽ chậm hơn, thời gian để compile code cũng chậm hơn
@@antonytran229 Ừa mình cũng thấy vậy :))
Rust nó quá đẳng cấp
Chắc phải theo học thôi
Ai cho mình link discord của kênh với, mình cảm ơn