Trình tạo bài kiểm tra hiệu năng (Benchmark) – JS Benchmark

Trình tạo bài kiểm tra hiệu năng JavaScript là gì?

Trình tạo bài kiểm tra hiệu năng JavaScript là công cụ so sánh thông lượng thực thi của các đoạn JavaScript trong trình duyệt. Người dùng cung cấp dữ liệu khởi tạo và những đoạn mã muốn khảo sát; công cụ gọi lặp từng đoạn, đo thời gian rồi trả về số lượt thực thi mỗi giây, gọi là Ops/sec. Kết quả được sắp xếp theo tốc độ và thể hiện bằng các thanh so sánh tương đối.

Trong phép đo này, một “lượt thực thi” là một lần gọi toàn bộ đoạn thử. Nếu đoạn thử chứa vòng lặp với nhiều phép tính, toàn bộ công việc đó vẫn chỉ được tính là một lượt. Vì vậy, Ops/sec không phải số phép toán CPU, cũng không tự cho biết chi phí riêng của từng câu lệnh.

Về phạm vi, đây là một công cụ microbenchmark: phép đo tập trung vào một phần xử lý nhỏ. Nó phù hợp để khảo sát những cách viết cùng thực hiện một công việc đồng bộ, chẳng hạn các cách ghép chuỗi. Nó không đo tốc độ tải trang, chất lượng kết nối mạng hay trải nghiệm của toàn bộ ứng dụng.

Kết quả trả lời câu hỏi “đoạn nào được gọi nhiều lần hơn trong một giây ở môi trường này”, không xác nhận đoạn mã đúng hoặc tối ưu trong mọi tình huống. Muốn lựa chọn phương án sử dụng thực tế, người dùng còn cần xét dữ liệu, tính đúng đắn và vai trò của đoạn xử lý trong ứng dụng.

Dữ liệu đầu vào và cách đọc kết quả benchmark

Chuẩn bị dữ liệu và các trường hợp tương đương

Đầu vào gồm mã khởi tạo, tên từng trường hợp và nội dung JavaScript cần thử. Mã khởi tạo chuẩn bị dữ liệu hoặc hàm dùng chung; tên giúp nhận diện kết quả; nội dung trường hợp là phần công việc được gọi lặp lại. Công cụ cho phép sửa các trường hợp, thêm trường hợp mới và xóa khi danh sách còn nhiều hơn một trường hợp.

Mã khởi tạo chạy riêng một lần cho mỗi trường hợp, không phải một lần cho cả bài benchmark. Trong cùng trường hợp, dữ liệu khởi tạo được dùng qua nhiều lượt gọi. Nếu đoạn thử thay đổi dữ liệu đó, thay đổi có thể tồn tại sang lượt tiếp theo; công cụ không tự đặt lại dữ liệu trước mỗi lần gọi.

Để so sánh có ý nghĩa, các trường hợp nên xử lý cùng dữ liệu và tạo kết quả tương đương. Một phương án xử lý toàn bộ danh sách không thể được so công bằng với phương án chỉ xử lý phần tử đầu tiên. Công cụ không tự kiểm tra sự tương đương này, cũng không hiển thị giá trị trả về để người dùng đối chiếu.

Đọc Ops/sec, thanh so sánh và trạng thái lỗi

Ops/sec lớn hơn biểu thị thông lượng cao hơn cho đoạn thử được nhập. Kết quả được sắp theo giá trị này từ cao xuống thấp. Thanh của mỗi trường hợp biểu diễn tỷ lệ giữa tốc độ của nó và tốc độ cao nhất trong cùng lượt benchmark; thanh cao nhất có tỷ lệ 100%.

Thanh 50% nghĩa là trường hợp đó đạt một nửa thông lượng của trường hợp dẫn đầu. Nó không phải tuyên bố tiết kiệm 50% thời gian, càng không phải mức cải thiện của toàn website. Khi đọc thanh, cần xem các đoạn thử có thực hiện cùng lượng công việc hay không.

Trường hợp gặp lỗi sẽ hiển thị thông báo thay vì tốc độ hợp lệ. Nhãn giao diện là “LỖI CÚ PHÁP”, nhưng nguyên nhân có thể nằm ở lúc khởi tạo hoặc lúc chạy, chẳng hạn truy cập một tên chưa được khai báo. Vì thế, nội dung thông báo cụ thể quan trọng hơn nhãn chung này.

Công cụ đo tốc độ và xếp hạng như thế nào?

Khởi tạo và khởi động trước khi đo

Các trường hợp được chạy tuần tự. Trước mỗi trường hợp, công cụ yêu cầu chờ 50 mili giây để trình duyệt có cơ hội cập nhật giao diện; khoảng chờ này không được tính vào Ops/sec. Sau đó, mã khởi tạo và đoạn thử được bao trong cấu trúc hàm động, giúp đoạn thử truy cập dữ liệu đã chuẩn bị.

Tiếp theo là 100 lượt khởi động. Những lượt này nằm ngoài thời gian dùng để tính tốc độ, nhưng vẫn thực thi công việc thật. Nếu đoạn thử thêm phần tử hoặc sửa dữ liệu, giai đoạn đo sẽ bắt đầu với trạng thái đã trải qua 100 lượt xử lý, không nhất thiết là trạng thái ban đầu.

Đếm lượt theo lô và tính Ops/sec

Khi bắt đầu đo, công cụ gọi đoạn thử theo từng lô 1000 lượt. Thời gian chỉ được kiểm tra sau khi hoàn tất một lô. Quy trình tiếp tục đến khi thời gian kiểm tra đạt ít nhất 1000 mili giây, nên không có việc cắt phép đo chính xác tại mốc một giây. Một lô chậm có thể khiến thời gian thực tế vượt mốc này đáng kể.

Công thức là: Ops/sec = làm tròn xuống (số lượt gọi đã đếm ÷ thời gian đo thực tế tính bằng giây). Phép đo vì vậy dùng thời lượng thực tế, không mặc định lấy số lượt chia cho đúng một giây. Chi phí gọi hàm, điều khiển vòng lặp và kiểm tra thời gian cũng góp vào khoảng đo.

Xếp hạng và xử lý đồng hạng

Thanh tương đối được tính bằng: Ops/sec của trường hợp ÷ Ops/sec cao nhất × 100%. Sau khi đo, danh sách được sắp giảm dần theo tốc độ. Mọi trường hợp thành công có cùng giá trị cao nhất đều có thể nhận nhãn “NHANH NHẤT”, miễn giá trị đó lớn hơn 0.

Nhãn “CHẬM NHẤT” dựa trên tốc độ thành công dương nhỏ nhất, chỉ xuất hiện khi giá trị này khác giá trị lớn nhất và danh sách có nhiều hơn một trường hợp. Nếu mọi kết quả thành công bằng nhau, không có nhãn chậm nhất. Trường hợp bị lỗi không được xem là một phép đo tốc độ thành công; công cụ chuyển tiếp sang trường hợp kế tiếp nếu lỗi được bắt.

Các thuật ngữ cần hiểu khi đọc JS benchmark

Microbenchmark

Microbenchmark là phép đo hiệu năng tập trung vào một công việc nhỏ, thay vì toàn bộ ứng dụng. Nó giúp khảo sát khác biệt giữa các cách thực hiện cùng thao tác. Điểm dễ nhầm là coi thứ hạng cục bộ như bằng chứng về tốc độ website: một đoạn xử lý nhanh hơn nhưng chỉ chiếm phần rất nhỏ trong tổng thời gian có thể không tạo ra cải thiện đáng nhận thấy.

Ops/sec

Ops/sec là số lượt thực thi mỗi giây, tức một đơn vị thông lượng. Trong công cụ này, một lượt là một lần gọi toàn bộ đoạn thử, dù bên trong chứa một biểu thức hay nhiều vòng lặp. Giá trị lớn hơn thường có lợi khi công việc tương đương, nhưng không phải số phép toán phần cứng. Nó cũng không trực tiếp biểu diễn thời gian phản hồi của một yêu cầu người dùng.

Warm-up

Warm-up là giai đoạn chạy trước khi thu số đo, nhằm tạo điều kiện cho môi trường thực thi ổn định hơn. Công cụ thực hiện 100 lượt warm-up cho mỗi trường hợp. Không nên hiểu rằng những lượt này không ảnh hưởng bài thử: chúng vẫn có thể sửa dữ liệu hoặc phát sinh lỗi. Chạy đủ số lượt khởi động cũng không bảo đảm mọi tối ưu hóa của trình duyệt đã hoàn tất.

JIT

JIT là cơ chế biên dịch hoặc tối ưu hóa mã trong quá trình chạy của bộ máy JavaScript. Đây là kiến thức nền giúp giải thích vì sao tốc độ có thể thay đổi theo lịch sử thực thi và vì sao có bước khởi động. Công cụ không đo hay báo cáo trạng thái JIT. Do đó, nhãn nhanh nhất không có nghĩa đoạn mã đã được tối ưu tuyệt đối hoặc sẽ giữ nguyên tốc độ trên mọi trình duyệt.

Closure

Closure là khả năng một hàm truy cập dữ liệu trong phạm vi bao quanh nơi nó được tạo. Công cụ sử dụng cơ chế này để đoạn thử dùng được dữ liệu khởi tạo của chính trường hợp đó. Dữ liệu có thể tồn tại qua nhiều lần gọi, chứ không tự được sao chép mới mỗi lần. Closure cũng không phải cơ chế cách ly an toàn: thay đổi lên trang hoặc trạng thái toàn cục vẫn có thể ảnh hưởng môi trường chung.

Ví dụ so sánh JavaScript và diễn giải kết quả

Ba cách nối chuỗi với cùng dữ liệu

Giả sử dữ liệu gồm hai chuỗi “Hello” và “World”, yêu cầu ghép chúng với một dấu cách ở giữa. Ba trường hợp mặc định minh họa các cách dùng toán tử cộng, template literal và ghép mảng bằng join. Với dữ liệu này, cả ba cách đều tạo chuỗi “Hello World” theo ngữ nghĩa JavaScript.

Nếu không phát sinh lỗi, mỗi trường hợp được khởi tạo riêng, chạy khởi động rồi đo, sau đó có một kết quả Ops/sec và thanh tương đối. Tuy nhiên, công cụ không hiển thị hoặc đối chiếu chuỗi được tạo. Không thể suy ra cách nào nhanh nhất chỉ từ mã nguồn; thứ hạng cần số đo trong một môi trường cụ thể.

Tính tốc độ từ số lượt và thời gian giả định

Ví dụ sau chỉ minh họa công thức, không phải kết quả chạy thực tế. Giả định trường hợp A được đếm 120000 lượt gọi trong 1,2 giây, còn trường hợp B được đếm 75000 lượt gọi trong 1,5 giây. Hai trường hợp thực hiện công việc tương đương và đều hoàn tất thành công.

A có tốc độ 120000 ÷ 1,2 = 100000 Ops/sec; B có tốc độ 75000 ÷ 1,5 = 50000 Ops/sec. Thanh B bằng 50000 ÷ 100000 × 100% = 50%. Nếu bài chỉ có hai trường hợp này, A nhận nhãn nhanh nhất và B nhận nhãn chậm nhất. Kết luận giới hạn ở thông lượng của bài thử giả định, không mở rộng thành mức tăng tốc toàn ứng dụng.

Trường hợp lỗi và đoạn thử rỗng

Giả sử một đoạn thử truy cập tên chưa được khai báo ngay lần gọi đầu tiên. Lỗi tham chiếu phát sinh trong warm-up sẽ được bắt; trường hợp đó không có tốc độ hợp lệ, nhưng trường hợp kế tiếp vẫn được xử lý. Giao diện dùng nhãn “LỖI CÚ PHÁP” dù nguyên nhân thực tế là lỗi tham chiếu.

Ngược lại, đoạn thử rỗng có thể được đo thành công nếu mã khởi tạo không gây lỗi. Khi đó, Ops/sec chủ yếu phản ánh thông lượng gọi hàm rỗng cùng chi phí bộ đo. Một con số cao trong tình huống này không chứng minh thuật toán thực tế nào nhanh hơn, bởi chưa có công việc hữu ích để so sánh.

Khi nào nên dùng benchmark để lựa chọn cách viết JavaScript?

Nên dùng công cụ khi cần khảo sát các cách thực hiện một công việc đồng bộ nhỏ và đã biết chúng tương đương về chức năng. Ví dụ, bạn có thể so sánh những cách biến đổi cùng một tập dữ liệu, với điều kiện mỗi trường hợp thực hiện đầy đủ yêu cầu giống nhau.

Dữ liệu thử nên có cấu trúc và kích thước gần nhu cầu thực tế. Kết quả với hai chuỗi ngắn không đủ để quyết định cách xử lý một tập văn bản lớn. Nếu ứng dụng phải đáp ứng nhiều kiểu đầu vào, nên khảo sát từng kiểu quan trọng thay vì dựa vào một ví dụ thuận lợi.

Kiểm tra tính đúng đắn cần thực hiện trước khi so tốc độ. Người dùng phải xác nhận đầu ra, cách xử lý dữ liệu rỗng và các trường hợp biên; đây không phải bước tự động của công cụ. Cũng cần kiểm tra liệu đoạn thử có thay đổi đầu vào khiến những lượt sau làm công việc khác lượt đầu hay không.

Bạn có thể tự chạy lại trong điều kiện tương tự để xem thứ hạng có ổn định. Đây là cách sử dụng kết quả, không phải tính năng thống kê tích hợp. Nếu khác biệt nhỏ hoặc thường đảo chiều, nên cân nhắc khả năng đọc, bảo trì và mức ảnh hưởng thực tế trước khi đổi cách viết. Một phương án dễ hiểu có thể phù hợp hơn một tối ưu cục bộ thiếu ổn định.

Benchmark đoạn mã khác gì kiểm thử đúng sai và đo toàn ứng dụng?

Tốc độ không thay thế tính đúng đắn

Kiểm thử đúng sai hỏi chương trình có đáp ứng yêu cầu hay không. Benchmark hỏi chương trình thực hiện công việc nhanh đến mức nào trong điều kiện đo. Hai mục tiêu này bổ sung cho nhau nhưng không thay thế nhau. Một đoạn mã bỏ qua dữ liệu khó xử lý có thể đạt thông lượng cao hơn mà vẫn không đáp ứng yêu cầu.

Công cụ hiện tại không đối chiếu đầu ra với kết quả mong đợi và không đánh giá các trường hợp có tương đương chức năng. Vì thế, “đo thành công” chỉ cho biết quy trình không gặp lỗi được bắt trong trường hợp đó, không phải chứng nhận tính đúng đắn.

Thông lượng cục bộ không thay thế hiệu năng toàn ứng dụng

Về kiến thức nền, profiling giúp xác định ứng dụng dành thời gian ở đâu, còn đo trải nghiệm toàn ứng dụng xét những hoạt động như tải dữ liệu, hiển thị và tương tác. Microbenchmark tách một đoạn nhỏ để khảo sát thông lượng. Đoạn đó nhanh hơn không có nghĩa website nhanh hơn theo cùng tỷ lệ, nhất là khi phần lớn thời gian nằm ở hoạt động khác.

Đo tác vụ bất đồng bộ lại cần theo dõi thời điểm công việc thật sự hoàn tất. Công cụ này gọi đoạn thử nhưng không đợi Promise hoặc yêu cầu mạng kết thúc. Vì vậy, nên chọn phương pháp từ câu hỏi cụ thể: cần biết tốc độ xử lý đồng bộ, thời gian chờ phản hồi hay nơi gây chậm trong toàn ứng dụng.

Giới hạn phép đo và lưu ý khi chạy mã nhập vào

Yếu tố làm kết quả dao động

Thiết bị, tải nền, bộ máy JavaScript và thứ tự chạy đều có thể ảnh hưởng số đo. Công cụ tạo một kết quả tổng hợp cho mỗi trường hợp trong một lượt benchmark, không có khoảng tin cậy hoặc thống kê nhiều mẫu độc lập. Với đoạn thử rất nhỏ, chi phí gọi hàm và vòng lặp có thể đáng kể; tối ưu hóa của bộ máy cũng có thể ảnh hưởng mạnh khi kết quả tính toán không được sử dụng.

Trạng thái dữ liệu và tác vụ bất đồng bộ

Tác dụng phụ trong warm-up và khi đo có thể làm các lượt xử lý khối lượng công việc khác nhau. Khởi tạo riêng không bảo đảm cách ly trạng thái toàn cục hoặc nội dung trang. Với tác vụ bất đồng bộ, bộ đo không chờ hoàn tất, nên thông lượng gọi không đại diện cho thời gian xử lý xong công việc. Những API hoặc thư viện do đoạn thử tham chiếu cũng chưa chắc có sẵn trong môi trường trang.

Mã không đáng tin cậy và nguy cơ treo trang

Các lô gọi chạy đồng bộ trên luồng giao diện. Mã chậm có thể làm trang tạm không phản hồi; vòng lặp vô hạn có thể khiến phép đo không kết thúc. Không có cơ chế hủy hoặc thời hạn cưỡng chế cho một lần gọi trong phần triển khai được cung cấp.

Chỉ nên chạy mã hiểu rõ và tránh đưa dữ liệu nhạy cảm vào bài thử. Không có căn cứ khẳng định mã được cách ly trong sandbox hoặc nội dung hiển thị được xử lý an toàn tuyệt đối. Cấu hình triển khai và các thành phần khác của website chưa được xác minh, nên cũng không thể cam kết dữ liệu chỉ xử lý cục bộ, không gửi đi hoặc không được lưu.

Câu hỏi thường gặp

Vì sao một trường hợp có thể mất hơn một giây để đo?

Vì công cụ kiểm tra thời gian sau mỗi lô 1000 lượt gọi, không ngắt giữa lô tại đúng mốc một giây. Nếu lô cuối mất nhiều thời gian, khoảng đo sẽ vượt mốc đó và tốc độ được tính theo thời lượng thực tế. Ngoài ra, thời gian chờ nhìn thấy trên giao diện còn bao gồm khởi tạo, 100 lượt khởi động và khoảng chờ cập nhật trang. Với nhiều trường hợp, các phần này diễn ra tuần tự nên tổng thời gian dài hơn.

Mã khởi tạo chạy một lần cho cả bài hay riêng cho từng trường hợp?

Mã khởi tạo chạy riêng một lần cho từng trường hợp, trước giai đoạn khởi động của trường hợp đó. Nó không chạy lại trước mỗi lượt gọi trong warm-up hoặc khi đo. Vì vậy, dữ liệu được chuẩn bị có thể tiếp tục thay đổi qua nhiều lượt nếu đoạn thử sửa nó. Cần phân biệt dữ liệu trong phạm vi khởi tạo với trạng thái dùng chung của trang: việc khởi tạo riêng không tự loại bỏ tác dụng phụ lên DOM, trạng thái toàn cục hoặc lưu trữ.

Vì sao chạy lại cùng đoạn mã nhưng Ops/sec thay đổi?

Vì môi trường thực thi không hoàn toàn cố định giữa các lần đo. Hoạt động nền, trạng thái thiết bị, cách bộ máy JavaScript tối ưu mã và độ phân giải bộ đếm thời gian đều có thể tác động đến kết quả. Dữ liệu hoặc trạng thái trang còn sót lại cũng có thể làm bài thử khác đi. Bạn nên giữ điều kiện tương tự và quan sát qua nhiều lần tự chạy; tuy nhiên, công cụ không tự tổng hợp các lần đó thành độ lệch chuẩn hay khoảng tin cậy.

Có thể dùng công cụ để đo Promise hoặc yêu cầu mạng không?

Không nên dùng kết quả này để kết luận về thời gian hoàn tất Promise hoặc yêu cầu mạng, vì bộ đo không chờ chúng kết thúc. Đoạn thử có thể liên tục khởi phát tác vụ rồi trả quyền điều khiển, khiến Ops/sec phản ánh tốc độ gọi hoặc lập lịch thay vì tốc độ hoàn thành. Việc tạo nhiều tác vụ cũng có thể gây tải ngoài ý muốn. Muốn trả lời câu hỏi về thời gian phản hồi, cần phương pháp theo dõi điểm bắt đầu và kết thúc thực sự của tác vụ.

Vì sao báo LỖI CÚ PHÁP khi nguyên nhân là lỗi lúc chạy?

Vì giao diện dùng chung nhãn “LỖI CÚ PHÁP” cho các lỗi được bắt trong quá trình xử lý một trường hợp. Nhánh này bao gồm lỗi tạo hàm, lỗi mã khởi tạo, lỗi warm-up và lỗi xuất hiện khi đo. Do đó, nhãn không phân loại chính xác mọi nguyên nhân. Hãy đọc thông báo đi kèm để phân biệt mã không hợp lệ với việc thiếu dữ liệu hoặc thiếu thành phần được tham chiếu. Trường hợp lỗi không có kết quả tốc độ hợp lệ để so sánh.

Ops/sec cao nhất có luôn là phương án nên chọn không?

Không. Giá trị cao nhất chỉ cho biết phương án dẫn đầu về thông lượng trong bài thử hiện tại. Để lựa chọn, còn cần bảo đảm nó cho đầu ra đúng, xử lý cùng lượng công việc và phù hợp với dữ liệu thật. Khả năng đọc, bảo trì và chi phí trong toàn ứng dụng cũng quan trọng. Nếu chênh lệch nhỏ, thiếu ổn định hoặc xuất hiện ở một phần hiếm khi chạy, đổi sang cách viết phức tạp hơn có thể không mang lại lợi ích đáng kể.

Công cụ có xuất báo cáo hoặc lưu lịch sử benchmark không?

Trong phần triển khai được cung cấp, không thấy chức năng xuất báo cáo hoặc lưu lịch sử benchmark. Kết quả được trình bày trên giao diện hiện tại, và khi chạy lại, vùng kết quả cũ được xóa trước khi đo mới. Vì vậy, không nên kỳ vọng có bản tải xuống hoặc bảng tổng hợp những lần trước. Điều này chỉ mô tả chức năng quan sát được trong mã, không chứng minh toàn website không có hoạt động ghi nhận hay lưu trữ dữ liệu ở thành phần khác.