Trang này được dịch bởi Cloud Translation API.

Phương pháp hay nhất cho ứng dụng RTB

Hướng dẫn này giải thích các phương pháp hay nhất cần cân nhắc khi phát triển ứng dụng theo Giao thức RTB.

Quản lý mối kết nối

Duy trì kết nối

Việc thiết lập một kết nối mới làm tăng độ trễ và tiêu tốn nhiều tài nguyên hơn ở cả hai đầu so với việc sử dụng lại một kết nối hiện có. Bằng cách đóng ít kết nối hơn, bạn có thể giảm số lượng kết nối phải mở lại.

Trước tiên, mọi kết nối mới đều yêu cầu một lượt truy cập mạng bổ sung để thiết lập. Vì chúng ta thiết lập kết nối theo yêu cầu, nên yêu cầu đầu tiên trên một kết nối có thời hạn hiệu quả ngắn hơn và có nhiều khả năng hết thời gian chờ hơn so với các yêu cầu tiếp theo. Mọi thời gian chờ bổ sung đều làm tăng tỷ lệ lỗi, điều này có thể dẫn đến việc trình đặt giá thầu bị điều tiết.

Thứ hai, nhiều máy chủ web tạo một luồng worker chuyên dụng cho mỗi kết nối được thiết lập. Điều này có nghĩa là để đóng và tạo lại kết nối, máy chủ phải tắt và loại bỏ một luồng, phân bổ một luồng mới, đặt trạng thái có thể chạy và tạo trạng thái kết nối, trước khi xử lý yêu cầu. Đó là một chi phí hao tổn không cần thiết.

Tránh đóng kết nối

Bắt đầu bằng cách điều chỉnh hành vi kết nối. Hầu hết các giá trị mặc định của máy chủ đều được điều chỉnh cho phù hợp với các môi trường có số lượng lớn ứng dụng, mỗi ứng dụng tạo ra một số lượng nhỏ yêu cầu. Ngược lại, đối với RTB, một nhóm nhỏ máy sẽ gửi yêu cầu thay mặt cho một số lượng lớn trình duyệt, tương đối. Trong những điều kiện này, bạn nên sử dụng lại các kết nối nhiều lần nhất có thể. Bạn nên đặt:

Thời gian chờ ở trạng thái rảnh là 2,5 phút.
Số lượng yêu cầu tối đa trên một kết nối với giá trị cao nhất có thể.
Số lượng kết nối tối đa với giá trị cao nhất mà RAM có thể chứa, đồng thời cẩn thận xác minh rằng số lượng kết nối không tiến gần đến giá trị đó quá nhiều.

Ví dụ: trong Apache, bạn cần đặt KeepAliveTimeout thành 150, MaxKeepAliveRequests thành 0 và MaxClients thành một giá trị tuỳ thuộc vào loại máy chủ.

Sau khi điều chỉnh hành vi kết nối, bạn cũng nên đảm bảo rằng mã bên đặt giá thầu không đóng các kết nối một cách không cần thiết. Ví dụ: nếu bạn có mã xử lý phía trước trả về phản hồi "không có giá thầu" mặc định trong trường hợp lỗi hoặc hết thời gian chờ của phần phụ trợ, hãy đảm bảo mã trả về phản hồi mà không đóng kết nối. Bằng cách đó, bạn tránh được tình huống nếu bên đặt giá thầu bị quá tải, các kết nối bắt đầu đóng và số lần hết thời gian chờ tăng lên, khiến bên đặt giá thầu bị điều tiết.

Giữ kết nối cân bằng

Nếu Người mua được uỷ quyền kết nối với máy chủ của bên đặt giá thầu thông qua một máy chủ proxy, thì các kết nối có thể mất cân bằng theo thời gian vì chỉ biết địa chỉ IP của máy chủ proxy, nên Người mua được uỷ quyền không thể xác định máy chủ bên đặt giá thầu nào đang nhận được từng lời gọi. Theo thời gian, khi Authorized Buyers thiết lập và đóng các kết nối và máy chủ của bên đặt giá thầu khởi động lại, số lượng kết nối được liên kết với từng kết nối có thể thay đổi rất nhiều.

Khi một số kết nối được sử dụng nhiều, các kết nối đang mở khác có thể chủ yếu ở trạng thái rảnh vì không cần thiết tại thời điểm đó. Khi lưu lượng truy cập của Người mua được uỷ quyền thay đổi, các kết nối rảnh có thể trở thành kết nối đang hoạt động và các kết nối đang hoạt động có thể chuyển sang trạng thái rảnh. Những điều này có thể gây ra tình trạng tải không đồng đều trên máy chủ của bên đặt giá thầu nếu các kết nối được nhóm không tốt. Google cố gắng ngăn chặn điều này bằng cách đóng tất cả các kết nối sau 10.000 yêu cầu để tự động cân bằng lại các kết nối nóng theo thời gian. Nếu vẫn thấy lưu lượng truy cập không cân bằng trong môi trường của mình, bạn có thể thực hiện thêm các bước sau:

Chọn phần phụ trợ cho mỗi yêu cầu thay vì một lần cho mỗi kết nối nếu bạn đang sử dụng proxy giao diện người dùng.
Chỉ định số lượng yêu cầu tối đa trên mỗi kết nối nếu bạn đang dùng proxy cho các kết nối thông qua bộ cân bằng tải phần cứng hoặc tường lửa và việc liên kết sẽ được cố định sau khi các kết nối được thiết lập. Xin lưu ý rằng Google đã chỉ định hạn mức trên là 10.000 yêu cầu cho mỗi kết nối,vì vậy, bạn chỉ cần cung cấp một giá trị nghiêm ngặt hơn nếu vẫn thấy các kết nối nóng bị tụ tập trong môi trường của mình. Ví dụ: trong Apache, hãy đặt MaxKeepAliveRequests thành 5.000
Định cấu hình máy chủ của bên đặt giá thầu để theo dõi tốc độ yêu cầu và đóng một số kết nối của chính họ nếu các máy chủ này liên tục xử lý quá nhiều yêu cầu so với các máy chủ khác.

Xử lý tình trạng quá tải một cách linh hoạt

Tốt nhất là bạn nên đặt hạn mức đủ cao để bên đặt giá thầu có thể nhận được tất cả các yêu cầu mà bên đặt giá thầu có thể xử lý, nhưng không được vượt quá hạn mức đó. Trong thực tế, việc duy trì hạn mức ở mức tối ưu là một nhiệm vụ khó khăn và tình trạng quá tải vẫn xảy ra vì nhiều lý do: phần phụ trợ ngừng hoạt động trong thời gian cao điểm, mức lưu lượng truy cập thay đổi nên cần xử lý nhiều hơn cho mỗi yêu cầu hoặc giá trị hạn mức được đặt quá cao. Do đó, bạn nên cân nhắc cách trình đặt giá thầu sẽ hoạt động khi có quá nhiều lưu lượng truy cập.

Để đáp ứng sự thay đổi tạm thời về lưu lượng truy cập (tối đa một tuần) giữa các khu vực (đặc biệt là giữa khu vực Châu Á và Hoa Kỳ phía Tây và Hoa Kỳ phía Đông và Hoa Kỳ phía Tây), bạn nên có khoảng đệm 15% giữa mức cao nhất trong 7 ngày và QPS trên mỗi Vị trí giao dịch.

Về hành vi khi có tải nặng, bên đặt giá thầu được chia thành ba danh mục lớn:

Bên đặt giá thầu "trả lời mọi thứ"

Mặc dù dễ triển khai, nhưng bên đặt giá thầu này hoạt động kém nhất khi bị quá tải. Phương thức này chỉ cố gắng phản hồi mọi yêu cầu đặt giá thầu đến, bất kể yêu cầu nào, đưa vào hàng đợi bất kỳ yêu cầu nào không thể phân phát ngay lập tức. Tình huống tiếp theo thường diễn ra như sau:

Khi tốc độ yêu cầu tăng lên, độ trễ yêu cầu cũng tăng lên cho đến khi tất cả yêu cầu bắt đầu hết thời gian chờ
Độ trễ tăng đột biến khi tỷ lệ chú thích đạt đến đỉnh
Tính năng điều tiết sẽ bắt đầu hoạt động, làm giảm mạnh số lượng chú thích được phép
Độ trễ bắt đầu hồi phục, làm giảm tình trạng điều tiết
Chu kỳ này sẽ bắt đầu lại.

Biểu đồ độ trễ của bên đặt giá thầu này giống như một mẫu răng cưa rất dốc. Ngoài ra, các yêu cầu xếp hàng khiến máy chủ bắt đầu phân trang bộ nhớ hoặc làm một việc khác gây ra tình trạng chậm trễ lâu dài và độ trễ hoàn toàn không khôi phục cho đến khi thời gian cao điểm kết thúc, dẫn đến tỷ lệ lời gọi bị giảm trong toàn bộ thời gian cao điểm. Trong cả hai trường hợp, sẽ có ít chú thích được tạo hoặc phản hồi hơn so với khi bạn chỉ đặt hạn mức ở mức thấp hơn.

Bên đặt giá thầu "lỗi khi quá tải"

Bên đặt giá thầu này chấp nhận chú thích ở một mức giá nhất định, sau đó bắt đầu trả về lỗi cho một số chú thích. Bạn có thể thực hiện việc này thông qua các khoảng thời gian chờ nội bộ, tắt tính năng xếp hàng kết nối (do ListenBackLog kiểm soát trên Apache), triển khai chế độ thả ngẫu nhiên khi mức sử dụng hoặc độ trễ quá cao hoặc một số cơ chế khác. Nếu Google nhận thấy tỷ lệ lỗi trên 15%, chúng tôi sẽ bắt đầu điều tiết. Không giống như bên đặt giá thầu "phản hồi mọi yêu cầu", bên đặt giá thầu này "giảm thiểu tổn thất", cho phép bên đặt giá thầu này khôi phục ngay lập tức khi tỷ lệ yêu cầu giảm xuống.

Biểu đồ độ trễ của bên đặt giá thầu này giống như một mẫu răng cưa nông trong quá trình quá tải, được định vị xung quanh tốc độ tối đa chấp nhận được.

Bên đặt giá thầu "không đặt giá thầu khi quá tải"

Bên đặt giá thầu này chấp nhận các chú thích với tốc độ nhất định, sau đó bắt đầu trả về phản hồi "không có giá thầu" cho mọi trường hợp quá tải. Tương tự như bên đặt giá thầu "lỗi khi quá tải", bạn có thể triển khai tính năng này theo một số cách. Điểm khác biệt ở đây là không có tín hiệu nào được trả về cho Google, vì vậy, chúng tôi không bao giờ giảm tốc độ chú thích. Máy phía trước sẽ hấp thụ tình trạng quá tải, chỉ cho phép lưu lượng truy cập mà chúng có thể xử lý tiếp tục chuyển đến phần phụ trợ.

Biểu đồ độ trễ của bên đặt giá thầu này cho thấy một mức ổn định (giả tạo) ngừng song song với tốc độ yêu cầu tại thời điểm cao điểm và sự sụt giảm tương ứng trong tỷ lệ phần trăm phản hồi chứa giá thầu.

Bạn nên kết hợp phương pháp "lỗi khi quá tải" với phương pháp "không đặt giá thầu khi quá tải" theo cách sau:

Cung cấp nhiều giao diện người dùng và đặt các giao diện này thành lỗi khi quá tải để giúp tăng tối đa số lượng kết nối mà các giao diện này có thể phản hồi theo một số hình thức.
Khi xảy ra lỗi quá tải, các máy phía trước có thể sử dụng phản hồi "không đặt giá thầu" có sẵn và không cần phân tích cú pháp yêu cầu.
Triển khai tính năng kiểm tra tình trạng của phần phụ trợ, chẳng hạn như nếu không có phần phụ trợ nào có đủ dung lượng, thì các phần phụ trợ đó sẽ trả về phản hồi "không có giá thầu".

Điều này cho phép hấp thụ một số tình trạng quá tải và giúp phần phụ trợ có cơ hội phản hồi chính xác số lượng yêu cầu mà chúng có thể xử lý. Bạn có thể coi trường hợp này là "không đặt giá thầu khi quá tải", trong đó các máy phía trước sẽ quay lại "lỗi khi quá tải" khi số lượng yêu cầu cao hơn đáng kể so với dự kiến.

Nếu bạn có bên đặt giá thầu "phản hồi mọi thứ", hãy cân nhắc chuyển đổi bên đặt giá thầu đó thành bên đặt giá thầu "lỗi khi quá tải" bằng cách điều chỉnh hành vi kết nối để bên đặt giá thầu đó từ chối bị quá tải. Mặc dù điều này khiến nhiều lỗi được trả về hơn, nhưng sẽ giảm thời gian chờ và ngăn máy chủ chuyển sang trạng thái không thể phản hồi bất kỳ yêu cầu nào.

Cân nhắc việc kết nối ngang hàng

Một cách khác để giảm độ trễ hoặc độ biến động của mạng là kết nối ngang hàng với Google. Tính năng liên kết ngang giúp tối ưu hoá đường dẫn lưu lượng truy cập đến bên đặt giá thầu của bạn. Các điểm cuối kết nối vẫn giữ nguyên, nhưng các đường liên kết trung gian sẽ thay đổi. Hãy xem Hướng dẫn về liên kết ngang để biết thông tin chi tiết. Có thể tóm tắt lý do để coi việc kết nối ngang hàng là phương pháp hay nhất như sau:

Trên Internet, các đường liên kết trung chuyển được chọn chủ yếu thông qua "tính năng định tuyến kiểu chuyển tiếp". Tính năng này tìm đường liên kết gần nhất bên ngoài mạng của chúng tôi có thể đưa gói đến đích và định tuyến gói qua đường liên kết đó. Khi lưu lượng truy cập đi qua một phần của xương sống do một nhà cung cấp sở hữu mà chúng tôi có nhiều kết nối ngang hàng, thì đường liên kết được chọn có thể nằm gần nơi gói bắt đầu. Sau điểm đó, chúng tôi không kiểm soát được tuyến đường mà gói theo đến bên đặt giá thầu, vì vậy, gói đó có thể bị trả về các hệ thống tự trị (mạng) khác trên đường đi.
Ngược lại, khi có thoả thuận liên kết trực tiếp, các gói sẽ luôn được gửi dọc theo đường liên kết liên kết. Bất kể gói bắt nguồn từ đâu, gói đó sẽ đi qua các đường liên kết mà Google sở hữu hoặc thuê cho đến khi đạt đến điểm liên kết ngang dùng chung, điểm này phải gần với vị trí của bên đặt giá thầu. Chuyến đi ngược lại bắt đầu bằng một bước chuyển ngắn đến mạng của Google và vẫn sử dụng mạng của Google trong suốt quãng đường còn lại. Việc giữ hầu hết hành trình trên cơ sở hạ tầng do Google quản lý đảm bảo rằng gói sẽ đi theo tuyến có độ trễ thấp và tránh được nhiều biến động tiềm ẩn.

Gửi DNS tĩnh

Người mua nên luôn gửi một kết quả DNS tĩnh duy nhất cho Google và dựa vào Google để xử lý việc phân phối lưu lượng truy cập.

Sau đây là hai phương pháp phổ biến của máy chủ DNS của bên đặt giá thầu khi cố gắng tải số dư hoặc quản lý tình trạng còn hàng:

Máy chủ DNS phân phát một địa chỉ hoặc một tập hợp con địa chỉ để phản hồi một truy vấn, sau đó luân phiên phản hồi này theo một cách nào đó.
Máy chủ DNS luôn phản hồi bằng cùng một nhóm địa chỉ, nhưng luân phiên thứ tự của các địa chỉ trong phản hồi.

Kỹ thuật đầu tiên không cân bằng tải tốt vì có nhiều hoạt động lưu vào bộ nhớ đệm ở nhiều cấp của ngăn xếp và việc cố gắng bỏ qua hoạt động lưu vào bộ nhớ đệm cũng có thể không mang lại kết quả mong muốn vì Google tính phí thời gian phân giải DNS cho bên đặt giá thầu.

Kỹ thuật thứ hai hoàn toàn không đạt được hiệu quả cân bằng tải vì Google chọn ngẫu nhiên một địa chỉ IP trong danh sách phản hồi DNS, vì vậy thứ tự trong phản hồi không quan trọng.

Nếu bên đặt giá thầu thay đổi DNS, Google sẽ tuân thủ TTL(Thời gian tồn tại) được đặt trong bản ghi DNS của bên đặt giá thầu, nhưng khoảng thời gian làm mới vẫn không chắc chắn.