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 xem xét 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 kết nối mới làm tăng độ trễ và tốn nhiều tài nguyên hơn ở cả hai đầu so với việc sử dụng lại 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 tôi thiết lập các kết nối theo yêu cầu, nên yêu cầu đầu tiên về 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 các yêu cầu tiếp theo. Mọi khoảng thời gian chờ vượt quá thời gian chờ làm tăng tỷ lệ lỗi, điều này có thể dẫn đến khi bên đặt giá thầu của bạn bị điều tiết.

Thứ hai, nhiều máy chủ web tạo ra một luồng worker chuyên dụng cho mỗi kết nối 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, cho phép luồng 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 các 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 môi trường có số lượng lớn máy khách, mỗi máy khách chỉ 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ỏ các máy sẽ gửi yêu cầu tương đối phù hợp cho một số lượng lớn trình duyệt. 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ể. T4 khuyên bạn nên đặt:

• Thời gian chờ khi không hoạt động 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, điều này sẽ đòi hỏi cài đặt KeepAliveTimeout đến 150, MaxKeepAliveRequests đến 0 và MaxClients thành một giá trị phụ 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ã của 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ã giao diện người dùng trả về trạng thái "không có giá thầu" mặc định phản hồi trong trường hợp phần phụ trợ lỗi hoặc hết thời gian chờ, hãy đảm bảo mã trả về phản hồi của nó mà không đóng kết nối. Bằng cách đó, bạn sẽ 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ữ các 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 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 ánh xạ đến từng cái có thể rất biến đổi.

Khi một số kết nối được sử dụng quá nhiều, các kết nối mở khác có thể chủ yếu ở trạng thái rảnh vì chúng chưa cần đến vào 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ả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 trạng thái nóng kết nối theo thời gian. Nếu bạn vẫn nhận thấy lưu lượng truy cập bị mất cân bằng trong , bạn có thể thực hiện thêm các bước sau:

1. 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.
2. Chỉ định số lượng yêu cầu tối đa cho mỗi kết nối nếu bạn thông qua trình cân bằng tải phần cứng hoặc tường lửa và ánh xạ được khắc phục sau khi kết nối được thiết lập. Xin lưu ý rằng Google đã chỉ định giới hạn 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 bạn vẫn thấy phổ biến các kết nối bị nhóm lại trong môi trường của bạn. Ví dụ: trong Apache, hãy đặt MaxKeepAliveRequests thành 5.000
3. Đị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ý 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, tỷ lệ 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 cần xem xét cách người đặt giá thầu của bạn sẽ hành xử với có quá nhiều lưu lượng truy cập vào.

Để phù hợp với những 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 Châu Á, miền Tây Hoa Kỳ, miền Đông và miền Tây Hoa Kỳ), chúng tôi đề xuất mức giảm 15% giữa mức cao nhất trong 7 ngày và QPS trên mỗi Giao dịch Vị trí.

Xét về hành vi dưới tải trọng lớn, bên đặt giá thầu được chia thành ba quy tắc chung danh mục:

Nút "đáp ứng mọi thứ" bên đặt giá thầu

Mặc dù dễ triển khai, nhưng bên đặt giá thầu này có hiệu suất kém nhất khi bị quá tải. Công cụ này chỉ cố gắng phản hồi mọi yêu cầu giá thầu xuất hiện, không bất kể là gì, đưa vào hàng đợi bất kỳ quảng cáo 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 cho đến khi tất cả các yêu cầu bắt đầu hết thời gian chờ
• Thời gian trễ tăng nhanh khi tỷ lệ chú thích sắp đạt đến mức cao nhất
• Điều tiết bắt đầu, làm giảm đáng kể số lượng chú thích được cho phép
• Độ trễ bắt đầu phục hồi, khiến mức điều tiết giảm
• Chu kỳ này sẽ bắt đầu lại.

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

Biểu đồ thời gian chờ cho bên đặt giá thầu này giống như hàm răng cưa nông mẫu trong quá trình nạp chồng, được bản địa hoá quanh phạm vi tối đa chấp nhận được .

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

Bên đặt giá thầu này chấp nhận các chú thích ở mức giá 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ều khác biệt ở đây là không tín hiệu được trả về cho Google, vì vậy, chúng tôi không bao giờ điều tiết chú thích. Chiến lược phát hành đĩa đơn các máy giao diện người dùng sẽ hấp thụ tình trạng quá tải, vốn chỉ cho phép lưu lượng truy cập mà họ có thể xử lý để tiếp tục đến phần phụ trợ.

Biểu đồ về thời gian chờ cho bên đặt giá thầu này cho thấy một giá trị giữ nguyên (một cách giả tạo) song song với tốc độ yêu cầu vào thời điểm cao điểm và mức giảm tương ứng tỷ lệ phần trăm phản hồi có chứa giá thầu.

Bạn nên kết hợp cả "lỗi quá tải" với thông báo "no-bid on quá tải" (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 kiểm tra tình trạng của hệ thống phụ trợ, sao cho nếu không có đủ dung lượng, hệ thống sẽ trả về trạng thái "no-bid" (không có giá thầu) của bạn.

Đ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ể nghĩ về điều này dưới dạng "không đặt giá thầu khi quá tải" với các máy giao diện người dùng gặp phải lỗi "lỗi 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.

Phản hồi ping

Việc đảm bảo bên đặt giá thầu có thể phản hồi các yêu cầu ping, mặc dù không phải là quản lý kết nối, lại đóng vai trò quan trọng trong quá trình gỡ lỗi. Google sử dụng các yêu cầu ping để kiểm tra tính hợp lệ và gỡ lỗi trạng thái của bên đặt giá thầu, hành vi đóng kết nối, độ trễ và nhiều thông tin khác. Yêu cầu ping có dạng sau:

id: "7xd2P2M7K32d7F7Y50p631"

{
  "id": "4YB27BCXimH5g7wB39nd3t"
}

id: "\3503cg\3023P\364\230\240\270\020\255\002\231\314\010\362\347\351\246\357("
is_test: true
is_ping: true

Lưu ý rằng, trái với những gì bạn có thể mong đợi, yêu cầu ping không chứa bất kỳ vùng quảng cáo. Và, như chi tiết ở trên, bạn không nên đóng kết nối sau khi phản hồi một yêu cầu ping.

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

Một cách khác để giảm độ trễ hoặc sự biến đổi 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. Chiến lược phát hành đĩa đơn điểm cuối của kết nối vẫn giữ nguyên, nhưng đường liên kết trung gian thì thay đổi. Xem Hướng dẫn kết nối ngang hàng để 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 "tuyến đường khoai tây nóng". Phương thức 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 đó. Thời gian lưu lượng truy cập truyền tải một phần trục chính thuộc sở hữu của nhà cung cấp mà chúng tôi nhiều kết nối ngang hàng, thì liên kết đã chọn có thể ở gần với nơi gói dữ liệu bắt đầu. Ngoài điểm đó, chúng tôi không còn quyền kiểm soát tuyến đường mà gói dữ liệu tuân theo bên đặt giá thầu, do đó nó có thể được gửi tới các hệ thống tự quản khác (mạng) trong quá trình thực hiện.

• Ngược lại, khi có thoả thuận ngang hàng trực tiếp, các gói sẽ luôn được gửi cùng một liên kết ngang hàng. 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:

1. Máy chủ DNS đưa ra một địa chỉ hoặc một tập hợp con các địa chỉ để phản hồi cho một truy vấn rồi duyệt qua phản hồi này theo một cách nào đó.
2. 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 không đạt được sự cân bằng tải vì Google chọn ngẫu nhiên một địa chỉ IP từ danh sách phản hồi DNS để 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.