AWS SDK cho Java làm ấm client trước request đầu tiên, nhưng có thêm một cuộc gọi mạng

Ngày 25/9/2026, bài giới thiệu SdkWarmUp của AWS xác nhận tiện ích có trong AWS SDK for Java 2.x từ phiên bản 2.54.0. Nó chạy trước đường xử lý của client để giảm phần việc ở request dịch vụ đầu tiên, nhưng tạo thêm một cuộc gọi mạng không ký nhằm chuẩn bị HTTP client.

Theo hướng dẫn SdkWarmUp của AWS, ứng dụng có thể làm ấm mọi service client trên classpath hoặc chỉ những client được chỉ định. Với Lambda SnapStart, lệnh cần chạy trong constructor của handler trước khi tạo snapshot; với dịch vụ chạy lâu dài, nó cần hoàn tất trước khi instance nhận lưu lượng. Sự đánh đổi là thời gian chuẩn bị chuyển sang giai đoạn khởi động.

Cuộc gọi mạng làm ấm phần nào?

Request dịch vụ đầu tiên có thể chậm hơn vì JVM còn phải nạp và khởi tạo các lớp của SDK, chạy mã xử lý request, rồi thiết lập kết nối. Quá trình kết nối có thể gồm tra cứu DNS, bắt tay TLS và xác thực chuỗi chứng chỉ. SdkWarmUp đưa phần chuẩn bị đường xử lý ấy lên trước request thật; nó không làm cho thời gian xử lý của chính dịch vụ AWS hay điều kiện mạng ở request thật biến mất.

Tiện ích chuẩn bị hai phần theo cách khác nhau. Service client thực hiện một thao tác cục bộ với phản hồi có sẵn để chạy qua mã tạo request và đọc phản hồi. HTTP client thực hiện một cuộc gọi mạng không ký tới endpoint AWS nhằm chuẩn bị mã thiết lập kết nối. Cuộc gọi này không gọi một thao tác dịch vụ, không cần credential hoặc quyền IAM và không phát sinh phí dịch vụ AWS; request thật vẫn cần cấu hình truy cập phù hợp.

Vì có kết nối mạng trong lúc làm ấm, thời gian khởi động không chỉ phụ thuộc vào CPU và việc nạp lớp Java. Đây là chi phí cần tính vào thời điểm ứng dụng được coi là sẵn sàng, nhất là khi ngân sách khởi động ngắn. Các trang AWS mô tả cơ chế và vị trí gọi, nhưng không đưa ra một mức giảm độ trễ chung để áp cho mọi ứng dụng.

Mốc công bố cũng khác mốc có mã. Ghi chú phát hành trên GitHub ghi bản 2.54.0 ra ngày 19/8/2026 và đã liệt kê cả cách làm ấm toàn classpath lẫn cách chỉ định client. Vì vậy, bài viết ngày 25/9 của AWS là lần giới thiệu tính năng, không phải ngày API lần đầu xuất hiện trong bản phát hành.

Chọn toàn classpath hay chọn từng client

SdkWarmUp.warmUp() không có đối số làm ấm các service client tìm thấy trên classpath, cùng các HTTP client mà chúng dùng. Lựa chọn này hợp với ứng dụng chỉ đóng gói một số ít module dịch vụ và sẽ gọi phần lớn client tương ứng. Mã khởi tạo cũng không cần liệt kê từng lớp client khi tập phụ thuộc của ứng dụng thay đổi.

Nếu dependency đưa vào các module dịch vụ không được sử dụng, lệnh không đối số vẫn dành thời gian làm ấm chúng. Khi đó, SdkWarmUp.warmUp(Class...) cho phép nêu đúng các lớp cần chuẩn bị. Chẳng hạn, SdkWarmUp.warmUp(S3Client.class, DynamoDbClient.class) là ví dụ cho ứng dụng dùng hai client đồng bộ ấy; nó không phải danh sách mặc định cho mọi ứng dụng Java trên AWS.

Kiểu lớp được truyền vào cũng có ý nghĩa. Một lớp client đồng bộ làm ấm đường xử lý đồng bộ, còn lớp bất đồng bộ làm ấm đường bất đồng bộ. Ứng dụng dùng cả hai kiểu cần chọn theo những đường thực sự có thể xuất hiện ở request đầu, thay vì chỉ theo tên dịch vụ. Sự khác biệt này dễ bị bỏ qua khi cùng một module cung cấp cả client đồng bộ và bất đồng bộ.

Tiêu chí triển khai là đối chiếu client mà lưu lượng ban đầu sẽ gọi với những module đang nằm trên classpath. Làm ấm toàn bộ phù hợp hơn khi hai tập đó gần trùng nhau. Chọn từng lớp có cơ sở hơn khi dependency rộng hoặc thời gian khởi động bị giới hạn, bởi thời gian chuẩn bị lúc ấy tập trung vào các client ứng dụng dự kiến sử dụng.

SnapStart: gọi trước khi tạo snapshot

Với hàm Java dùng Lambda SnapStart, AWS đặt SdkWarmUp.warmUp() trong constructor của handler. Lambda chạy constructor trong giai đoạn khởi tạo rồi mới tạo snapshot, nên phần mã SDK đã được làm ấm có thể được ghi vào trạng thái phục hồi. Nếu đợi đến phương thức xử lý request mới gọi lệnh, công việc chuẩn bị lại nằm trên đường đi của request đầu tiên.

Mẫu tích hợp là nhập software.amazon.awssdk.core.warmup.SdkWarmUp và gọi SdkWarmUp.warmUp() trong constructor. Handler có nhiều module AWS không dùng có thể thay bằng lời gọi liệt kê các lớp client cần thiết. Lệnh làm ấm tự nó không cần credential; điều đó không thay thế credential và quyền IAM cho thao tác AWS thật mà handler thực hiện sau khi được khôi phục.

Snapshot lưu trạng thái khởi tạo đã qua bước làm ấm, nhưng không nên hiểu đó là cam kết rằng một kết nối mạng mở lúc khởi tạo sẽ luôn được tái sử dụng sau phục hồi. Lợi ích được AWS mô tả là request sau khi restore không phải tự kích hoạt toàn bộ đường xử lý SDK từ đầu. Độ trễ cuối cùng vẫn phụ thuộc vào thao tác dịch vụ và môi trường chạy của hàm.

Container và EC2: hoàn tất trước khi nhận lưu lượng

SdkWarmUp cũng áp dụng cho dịch vụ Java chạy trong container hoặc trên Amazon EC2. Vị trí gọi tương ứng là lúc khởi động ứng dụng, trước khi instance đăng ký với bộ cân bằng tải hoặc báo healthy. Nếu báo sẵn sàng trước khi lệnh hoàn tất, request đầu vẫn có thể tới trong lúc SDK đang chuẩn bị đường xử lý.

Ở mô hình này, làm ấm kéo dài khoảng thời gian từ lúc tiến trình bắt đầu đến khi instance phục vụ được lưu lượng, đổi lại request đầu không phải gánh cùng phần khởi tạo ấy. Đây là khác biệt vận hành so với SnapStart: dịch vụ chạy lâu dài trả chi phí khi mỗi tiến trình mới khởi động, còn SnapStart đặt công việc trước lúc tạo snapshot dùng cho các lần khôi phục.

Đo thời gian khởi động cùng request đầu

Đánh giá tính năng cần tách thời gian khởi động khỏi độ trễ request thật đầu tiên. Chỉ đo request đầu sẽ bỏ sót phần việc đã được chuyển lên trước khi ứng dụng sẵn sàng. Chỉ đo lúc khởi động lại không cho thấy liệu đường request mà ứng dụng cần có được cải thiện hay không. Hai khoảng thời gian này cùng quyết định cấu hình warm-up có phù hợp với workload.

Với SnapStart, có thể ghi nhận thời gian khởi tạo phiên bản được chụp snapshot và độ trễ của cùng loại request sau khi khôi phục. Với container hoặc EC2, các mốc tương ứng là lúc JVM bắt đầu, lúc instance báo healthy và lúc request đầu hoàn tất. Đây là cách so sánh được đề xuất cho ứng dụng cụ thể, không phải kết quả benchmark do AWS công bố.

So sánh lời gọi không đối số với lời gọi chọn lớp trong cùng điều kiện sẽ cho thấy liệu các dependency dư có làm tăng thời gian chuẩn bị hay không. Nếu cả hai đều làm ấm đúng đường request đầu, chênh lệch thời gian khởi động sẽ giúp quyết định cấu hình. Hiện đã có API, hướng dẫn vị trí gọi và mốc phiên bản; các nguồn được kiểm tra chưa công bố một mức cải thiện hiệu năng có thể áp dụng chung cho mọi workload.

Đọc thêm:

• AWS đặt thêm 2 triệu GPU Nvidia: công suất mới chỉ đến từ 2027
• Copilot có thể duyệt pull request: một thiết lập sẽ biến nhận xét thành phê duyệt
• F5 chặn lệnh của AI agent trước khi chạy: tháng 10 mới có