10/10/2026 · VietTechies · Biên tập
Khi chạy tiến trình build trên các monorepo JavaScript lớn, các công cụ build thường rơi vào tình trạng số lượng tác vụ đã sẵn sàng vượt quá số nhân CPU hoặc luồng xử lý hiện có. Trong bối cảnh tài nguyên bị giới hạn này, thứ tự điều phối các tác vụ có thể ảnh hưởng đáng kể đến tổng thời gian hoàn thành. Phân tích do đội ngũ duy trì công cụ chạy tác vụ vx công bố cho thấy: chỉ riêng việc thay đổi thứ tự điều phối tác vụ đã khiến tổng thời gian thực thi chênh lệch tới một phần ba trên cùng một cấu hình phần cứng và luồng xử lý.
Thuật toán phỏng đoán tĩnh và sự bất định của thời gian thực thi
Theo mặc định, vx sử dụng thuật toán phỏng đoán dựa trên đồ thị có hướng không chu trình (DAG) tĩnh, ưu tiên các tác vụ sẵn sàng có nhiều tác vụ phụ thuộc gián tiếp nhất. Chiến lược này dựa trên giả định rằng tác vụ đang chặn nhiều công việc nhất chính là tác vụ nằm trên đường găng (critical path). Trong môi trường thử nghiệm đồng nhất nơi mọi tác vụ có thời gian chạy như nhau, các quy tắc phỏng đoán dựa trên đồ thị chỉ chậm hơn giới hạn lý thuyết tối ưu trong khoảng ba giây. Trong bài đo hiệu năng tổng hợp gồm 1.090 gói phần mềm và 3.270 tác vụ trên 100 lớp phụ thuộc với 10 luồng xử lý, quy tắc dựa trên đồ thị hoàn thành gần như ở mức tối ưu, trong khi cách chạy theo thứ tự sẵn sàng tùy ý lại chậm hơn 37%.
Tuy nhiên, các tác vụ monorepo trong thực tế hiếm khi có thời gian thực thi bằng nhau. Thuật toán phỏng đoán đồ thị tĩnh bộc lộ hạn chế khi gặp các tác vụ cô lập chạy lâu, chẳng hạn như kiểm tra kiểu dữ liệu (typecheck) hoặc kiểm tra định dạng mã nguồn (linter) độc lập vốn không có tác vụ phụ thuộc phía sau. Trong các bài thử nghiệm tổng hợp thực hiện vào ngày 9 tháng 10 năm 2026 bằng Bun 1.4.2 trên máy Linux 4 nhân, quy tắc phụ thuộc gián tiếp mặc định của vx khiến thời gian chạy chậm hơn 49% so với thứ tự vào trước – ra trước (FIFO) trên một đồ thị chứa duy nhất một tác vụ cô lập kéo dài 60 giây. Do tác vụ kéo dài này không có phụ thuộc phía sau, thuật toán đồ thị đã trì hoãn việc khởi chạy nó. Ngược lại, cách chạy theo thứ tự sẵn sàng lại làm tăng 9% thời gian thực thi trên khối lượng công việc gồm 100 tác vụ độc lập cùng một chuỗi phụ thuộc hai tác vụ, chứng minh rằng các thuật toán phỏng đoán tĩnh luôn dễ gặp thất bại trước các cấu trúc đồ thị đặc thù.
Dữ liệu thời gian chạy trong lịch sử và kiến trúc plugin
Để vượt qua giới hạn của thuật toán phỏng đoán đồ thị tĩnh mà không cần ước tính thủ công thời gian cho từng loại công cụ, vx cung cấp plugin @vzn/vx-schedule-history. Thay vì đoán độ dài tác vụ dựa trên số lượng tệp đầu vào hay nhãn tác vụ, plugin này ghi lại thời gian thực thi thực tế tại máy cục bộ từ 20 lần chạy gần nhất. Từ lần chạy thứ hai trở đi, bộ lập lịch sẽ kết hợp thời gian của từng tác vụ đã ghi nhận với chuỗi thời gian lịch sử dài nhất phía sau để tính toán chính xác đường găng thực tế.
Đối với môi trường CI nơi các máy chạy build khởi tạo mà không có trạng thái cục bộ từ trước, plugin cho phép các đội ngũ lưu giữ thời gian trung vị đã ghi nhận vào một tệp bộ nhớ tạm chung qua các lần build. Các nhà phát triển cũng có thể định nghĩa thời gian dự phòng thủ công cho lần chạy đầu tiên thông qua tùy chọn assume trong tệp vx.workspace.ts. Động cơ lập lịch bên dưới công khai thuật toán tính độ ưu tiên qua hàm criticalPathPriorities, cho phép các plugin tùy chỉnh đọc dữ liệu thời gian từ hệ thống lưu trữ chỉ số trung tâm của doanh nghiệp.
Ý nghĩa của bộ lập lịch nhận biết thời gian thực thi đối với các đội ngũ kỹ thuật
Các tổ chức phát triển phần mềm hiện đại ngày càng phụ thuộc vào monorepo để quản lý các cơ sở mã nguồn phức tạp, nhưng quy mô dự án mở rộng thường kéo theo những điểm nghẽn nghiêm trọng về hiệu năng build. Các bài đo hiệu năng do vx công bố làm nổi bật một thực tế vận hành cốt lõi: phân tích mã nguồn tĩnh và kiểm tra đồ thị phụ thuộc không thể tự mình dự đoán chính xác hiệu năng build. Bởi lẽ các tác vụ xác minh mã nguồn như linting, kiểm thử đơn vị và kiểm tra kiểu dữ liệu có mô hình sử dụng tài nguyên hoàn toàn khác biệt so với các công cụ đóng gói (bundler) hoặc biên dịch nặng, một bộ lập lịch tĩnh sẽ luôn hoạt động với những điểm mù nghiêm trọng.
Việc chỉ dựa vào cây phụ thuộc cấu trúc dẫn đến phân bổ tài nguyên không tối ưu, khiến các nút build CI nhiều nhân đắt đỏ rơi vào trạng thái nhàn rỗi trong khi các tác vụ chạy lâu đã giải phóng phụ thuộc lại phải nằm chờ trong hàng đợi. Bằng cách áp dụng các plugin lập lịch nhận biết thời gian chạy và lưu bộ nhớ tạm các chỉ số thực thi trong chuỗi tích hợp liên tục (CI), các đội ngũ phát triển có thể thu hồi dung lượng tính toán đáng kể mà không cần sửa đổi mã nguồn hay kiến trúc ứng dụng. Việc thu thập thời gian chạy thực tế trong lịch sử biến bài toán lập lịch build từ một chuỗi các phỏng đoán thành một bài toán tối ưu hóa đường găng mang tính định đề. Khi chi phí CI tăng lên cùng với kích thước kho lưu trữ mã nguồn, việc điều phối tác vụ dựa trên thời gian thực thi đại diện cho một trong những điểm tựa kỹ thuật hiệu quả nhất để giảm thiểu thời gian chờ đợi của nhà phát triển và tiết kiệm chi phí hạ tầng.
Ảnh minh họa do AI tạo, không phải ảnh tư liệu.