Skip to content

Cloudflare thêm công cụ tìm điểm nghẽn CPU và bộ nhớ trên Workers

Cloudflare cho phép thu hồ sơ CPU và bộ nhớ ngay trên Workers và Durable Objects đang vận hành, giúp đội phát triển xác định đoạn mã gây tốn tài nguyên thay vì chỉ dựa vào log.

•6 min read
Chia sẻ:
Flamegraph minh họa việc khoanh vùng hàm tốn tài nguyên

Cloudflare công bố khả năng thu hồ sơ sử dụng CPU và bộ nhớ theo yêu cầu cho Workers và Durable Objects. Công cụ cho phép nhà phát triển quan sát mã đang chạy trong môi trường thực tế, xem kết quả bằng biểu đồ flamegraph và tải tệp về để phân tích thêm.

Điểm đáng chú ý không chỉ là thêm một màn hình giám sát. Khi ứng dụng chậm hoặc gặp lỗi thiếu bộ nhớ, log và chỉ số tổng hợp thường cho biết triệu chứng, nhưng chưa chỉ ra hàm nào gây ra vấn đề. Profiling bổ sung góc nhìn ở cấp mã nguồn, giúp đội vận hành khoanh vùng công việc tiêu tốn tài nguyên.

Từ chỉ số tổng hợp đến từng hàm trong ứng dụng

Theo thông báo về profiling cho Workers và Durable Objects của Cloudflare, người dùng có thể yêu cầu thu hồ sơ CPU hoặc bộ nhớ từ trang Workers Observability, chọn phiên bản Worker và thời lượng ghi nhận. Kết quả được hiển thị dưới dạng flamegraph tương tác, đồng thời có thể tải xuống để mở bằng công cụ phân tích khác.

Trong biểu đồ này, mỗi hình chữ nhật đại diện cho một lời gọi hàm. Chiều rộng thể hiện mức CPU hoặc bộ nhớ mà hàm sử dụng trong hồ sơ. Người dùng có thể bấm để tập trung vào một nhánh gọi hàm, hoặc chuyển sang dạng bảng để tìm những hàm xuất hiện nhiều trong mẫu thu thập.

Khác biệt với kiểm tra cục bộ nằm ở tải thực tế. Cloudflare cho biết Workers đã hỗ trợ profiling cục bộ qua Chrome DevTools, nhưng dữ liệu từ máy phát triển không phản ánh đầy đủ loại yêu cầu và lưu lượng mà ứng dụng nhận khi vận hành.

Một đoạn xử lý nhỏ có thể không đáng chú ý trong thử nghiệm, nhưng trở thành chi phí lớn khi được gọi liên tục. Đây cũng là lý do profiling cần được đọc cùng bối cảnh lưu lượng, thay vì xem một biểu đồ là kết luận cho mọi tình huống.

Hai ví dụ cho thấy phần việc thừa có thể bị che khuất

Hai đường duyệt trùng lặp trên cây dữ liệu JSON

Cloudflare đưa ra ví dụ từ Worker triển khai binding cho dịch vụ lưu trữ R2. Trong hồ sơ CPU, nhóm phát hiện một hàm thay thế giá trị khi chuyển dữ liệu sang JSON chiếm hơn 5% thời gian CPU.

Vấn đề là hàm này tự duyệt cây dữ liệu, trong khi JSON.stringify cũng gọi nó tại từng nút. Theo mô tả của công ty, một giá trị nằm sâu năm cấp bị xử lý năm lần. Loại bỏ công việc trùng lặp giúp riêng hàm đó chạy nhanh hơn 2,7 lần. Con số này không đồng nghĩa toàn bộ ứng dụng nhanh hơn cùng tỷ lệ.

Một trường hợp khác liên quan đến bộ nhớ. Cloudflare cho biết nhóm nội bộ phát hiện mã Prometheus chiếm khoảng 66,7% lượng cấp phát trong hồ sơ của một Worker gặp lỗi vượt giới hạn bộ nhớ. Nhóm trước đó cho rằng phần mã này đã bị vô hiệu hóa, nhưng thực tế nó vẫn thu thập dữ liệu ở nhiều đường thực thi.

Sau khi loại bỏ hoàn toàn đường mã đó, mức bộ nhớ ở phân vị P999 giảm từ 133 MB xuống 118 MB, theo số liệu Cloudflare công bố. Ví dụ cho thấy cấu hình được hiểu là “đã tắt” chưa chắc đã loại bỏ chi phí xử lý. Tuy nhiên, đây là kết quả của một hệ thống nội bộ, không phải mức cải thiện được bảo đảm cho mọi Worker.

Cần đủ lưu lượng và tên hàm có thể đọc được

Source map nối hồ sơ thực thi với các phần mã nguồn

Để thu hồ sơ từ bảng điều khiển, nhà phát triển vào danh sách Workers, chọn ứng dụng, mở tab Observability rồi chọn Flamegraph. Cloudflare cũng cung cấp cách thực hiện qua dòng lệnh bằng gói cf.

Có hai điều kiện ảnh hưởng trực tiếp đến giá trị của kết quả. Thứ nhất, phiên bản Worker được chọn cần có đủ lưu lượng để profiling thành công. Một phiên bản gần như không nhận yêu cầu có thể không tạo được hồ sơ hữu ích.

Thứ hai, với dự án TypeScript, Cloudflare khuyến nghị bật source map. Nếu thiếu thông tin ánh xạ về mã nguồn, hồ sơ có thể hiển thị tên hàm đã bị biến đổi, khiến việc nối kết điểm nghẽn với mã cần sửa khó hơn.

Công ty cũng khuyến nghị thu vài hồ sơ thay vì chỉ nhìn một lần. Về mặt phân tích, cách này giúp phân biệt một mẫu nổi bật nhất thời với phần công việc thường xuyên tiêu tốn tài nguyên. Hồ sơ bộ nhớ cho thấy nơi cấp phát đáng chú ý, nhưng chỉ riêng nó chưa đủ để khẳng định ứng dụng có rò rỉ bộ nhớ.

Ý nghĩa với các ứng dụng đã đi vào vận hành

Công cụ mới bổ sung lớp quan sát cho những đội xây website, API hoặc ứng dụng nội bộ trên Workers. Thay vì suy đoán từ lỗi “Exceeded Memory” hay mức CPU tăng, đội phát triển có thêm dữ liệu để chọn đoạn mã cần kiểm tra trước.

Đây là bước tiếp theo sau câu chuyện tạo ứng dụng: mã chạy được chưa có nghĩa mã vận hành ổn định. Với các công cụ nội bộ được xây nhanh, bài toán quan sát tài nguyên bổ sung cho những yêu cầu về dữ liệu và quyền truy cập được đề cập trong bài nhân viên tự xây ứng dụng AI và bài toán quản trị.

Thông báo này cũng làm rõ một phần hướng mở rộng công cụ phát triển của Cloudflare, bên cạnh các cập nhật được tổng hợp trong bản tin về hạ tầng ứng dụng ngày 09/10 và bản tin công nghệ ngày 10/10.

Những ví dụ công bố cho thấy profiling có thể phát hiện công việc lặp và chi phí từ mã tưởng đã ngừng hoạt động. Mức cải thiện của từng ứng dụng vẫn phụ thuộc vào đường thực thi, tải thực tế và thay đổi được triển khai sau khi phân tích; công cụ cung cấp bằng chứng để điều tra, không tự sửa điểm nghẽn.

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

Flamegraph có chiều rộng lớn có luôn chỉ ra lỗi không?

Không. Một hàm có thể dùng nhiều tài nguyên vì đang thực hiện công việc cần thiết, chẳng hạn xử lý dữ liệu. Chiều rộng giúp xác định nơi nên điều tra trước; cần xem mã và yêu cầu nghiệp vụ để biết có thể tối ưu hay không.

Có thể dùng mức tăng tốc 2,7 lần làm dự báo cho ứng dụng khác không?

Không. Đây là kết quả Cloudflare công bố cho một hàm cụ thể sau khi bỏ xử lý trùng lặp. Tác động lên toàn ứng dụng phụ thuộc vào tỷ trọng của hàm đó và các phần việc còn lại.

Bài viết liên quan

Gợi ý đọc thêm

Chia sẻ: