- Trong môi trường JavaScript và Node.js, Joi, một thư viện xác thực, có hiệu năng chậm hơn các thư viện khác
- Nếu thay Joi bằng thư viện khác, có thể kỳ vọng cải thiện hiệu năng trong môi trường backend
- Kiểm tra xem liệu trong ứng dụng backend có xuất hiện khác biệt hiệu năng đủ ý nghĩa hay không
- Tiến hành thử nghiệm bằng k6, đồng thời kiểm thử cả lodash và class-transformer
- Kết quả kiểm thử hiệu năng:
- native vs lodash: không có khác biệt hiệu năng
- object literal vs class-transformer: không có khác biệt hiệu năng
- non-validation vs Joi: dù Joi có hiệu năng chậm hơn, vẫn không xuất hiện khác biệt hiệu năng
- Hiệu năng là quan trọng, nhưng với các dự án đã và đang triển khai, khi thay đổi có thể sẽ không cảm nhận được khác biệt hiệu năng tương xứng với thời gian đầu tư
8 bình luận
Tôi nghĩ có lẽ tác giả không nhằm mục tiêu cải thiện tình huống nghẽn cổ chai, mà muốn lập luận rằng trong môi trường tương tự với tình huống thực tế thì chênh lệch hiệu năng giữa các thư viện kiểm tra tính hợp lệ không quá đáng kể.
Nếu giả sử đây không phải là dịch vụ chỉ có các tác vụ
io bound tasknhư tác giả mô tả trong bài, mà là một dịch vụ cócpu bound task, thì sẽ thế nào?Các dịch vụ trong môi trường thực tế phức tạp hơn chúng ta nghĩ. Máy chủ không chỉ là API phục vụ dữ liệu cần thiết để hiển thị UI.
Validation và công việc JSON serialization đều là các phép tính diễn ra trên main thread, nên không thể xem nhẹ được. Ở hệ backend TS, thứ được dùng phổ biến nhất là class-validator/class-transformer. Và khả năng xử lý kiểm tra hợp lệ của bộ này vào khoảng 4MB mỗi giây, điều đó có nghĩa là main thread không thể xử lý quá 4MB mỗi giây.
Còn I/O với DB thì hoạt động trên background thread chứ không phải main thread, nên xét theo server backend (server TS) thì nó không ảnh hưởng quá lớn đến số lượng kết nối đồng thời. Tùy tính chất của dịch vụ, nếu lượng DTO được truyền trong một lần lớn thì validation chậm còn đáng sợ hơn (thực tế đã từng có trường hợp khi làm một dịch vụ có dữ liệu lớn cho mỗi request, số kết nối đồng thời của NestJS chỉ ở mức một chữ số).
Tôi đồng ý, để có thể lấy tiền đề là như tác giả nói, "trong tình huống thực tế", thì ví dụ về tình huống thực tế được đưa ra lại quá phiến diện.
Đúng như người ở trên đã nói, đây là một bài benchmark khó hiểu vì không rõ tại sao lại đưa I/O của DB vào. Ngoài ra, validation và serialization chậm gây hại đến hiệu năng máy chủ ở response DTO nhiều hơn là ở request DTO. Cuối cùng, khi làm các thí nghiệm benchmark kiểu này thì không nên chỉ dùng một DTO, mà phải thử với nhiều loại khác nhau.
Trên thực tế, khi không có DB I/O và thử nghiệm các DTO có cấu trúc đa dạng, kết quả sẽ khác nhau.
Ngay từ đầu có vẻ như phía kết nối DB mới là nút thắt cổ chai, nên tôi tự hỏi liệu chủ đề có đang bị đặt sai hay không.
Có vẻ như bài này được trình bày như thể có cải thiện hiệu năng dù thực ra không có, nhưng trên thực tế ngay từ đầu phía DB mới là điểm nghẽn, nên việc bài viết tập trung vào cải thiện những chỗ không phải điểm nghẽn có thể dễ gây hiểu lầm.
Trong hầu hết môi trường, cải thiện hiệu năng đồng nghĩa với việc giải quyết điểm nghẽn; khi tối ưu hóa việc kiểm tra tính hợp lệ, trước hết cần xác định rằng chính phần kiểm tra tính hợp lệ là điểm nghẽn.