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ì các kết nối

Việc thiết lập kết nối mới sẽ làm tăng độ trễ và tốn nhiều tài nguyên ở cả hai đầu so với việc sử dụng lại kết nối hiện có. Khi đó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 phải thiết lập thêm một mạng khứ hồi. 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 cho một kết nối có thời hạn có hiệu lực ngắn hơn và có nhiều khả năng hết thời gian chờ so với các yêu cầu tiếp theo. Việc vượt quá thời gian chờ sẽ làm tăng tỷ lệ lỗi, điều này có thể khiến bên đặ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, làm cho 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. Tốn rất nhiều chi phí 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 hoạt động 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 ứng dụng lớn, mỗi môi trường đưa ra một số ít yêu cầu. Ngược lại, đối với RTB, nói tương đối thì một số ít máy sẽ gửi yêu cầu thay cho một số lượng lớn các trình duyệt. Trong các đ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ờ 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 đến giá trị cao nhất có thể.
  • Số lượng kết nối tối đa đến giá trị cao nhất mà RAM có thể đáp ứng, đồng thời chú ý xác minh rằng số lượng kết nối không gần với giá trị đó.

Ví dụ: trong Apache, việc này sẽ đòi hỏi việc đặt KeepAliveTimeout thành 150, MaxKeepAliveRequests thành 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 phải đảm bảo rằng mã bên đặt giá thầu không đóng 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ề phản hồi mặc định "không có giá thầu" trong trường hợp có lỗi phụ trợ hoặc hết thời gian chờ, 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 sẽ tránh được trường hợp bên đặt giá thầu bị quá tải, việ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.

Duy trì sự cân bằng giữa các kết nối

Nếu Authorized Buyers kết nối với máy chủ của bên đặt giá thầu thông qua máy chủ proxy, thì các mối 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, Authorized Buyers không thể xác định máy chủ bên đặt giá thầu nào đang nhận từng chú thích. Theo thời gian, khi Authorized Buyers thiết lập và đóng mối kết nối cũng như máy chủ của bên đặt giá thầu khởi động lại, số lượng mối kết nối được liên kết với từng mối kết nối có thể thay đổi nhiều.

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ể hầu như không hoạt động vì hiện tại chúng không cần thiết. Khi lưu lượng truy cập của Authorized Buyers thay đổi, kết nối ở trạng thái rảnh có thể trở thành kết nối đang hoạt động và kết nối đang hoạt động có thể không hoạt động. Những vấn đề 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 đường kết nối được nhóm kém. Google cố gắng ngăn chặn điều này bằng cách đóng mọi kết nối sau 10.000 yêu cầu, để tự động điều chỉnh 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ể làm 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. Hãy chỉ định số lượng yêu cầu tối đa cho mỗi kết nối nếu bạn đang kết nối proxy thông qua trình cân bằng tải phần cứng hoặc tường lửa và mối liên kết này sẽ đượ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 vẫn thấy kết nối nóng bị nhóm lại trong môi trường của mình. 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 giá yêu cầu của họ và đóng một số kết nối của riêng họ nếu máy chủ đó đang xử lý quá nhiều yêu cầu một cách nhất quán so với các máy chủ ngang hàng.

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

Tốt nhất là nên đặt hạn mức đủ cao để bên đặt giá thầu có thể nhận được tất cả yêu cầu mà họ có thể xử lý, nhưng không nhiều hơn thế. 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 xảy ra vì nhiều lý do: phần phụ trợ ngừng hoạt động vào giờ cao điểm, kết hợp lưu lượng truy cập thay đổi để cần phải xử lý nhiều hơn cho mỗi yêu cầu hoặc giá trị hạn mức chỉ được đặt quá cao. Do đó, bạn nên xem xét hành vi của bên đặt giá thầu 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 Châu Á và miền Tây Hoa Kỳ cũng như miền Đông và miền Tây Hoa Kỳ), bạn nên giảm 15% trong khoảng thời gian từ mức cao nhất 7 ngày đến QPS cho mỗi vị trí giao dịch.

Xét về hành vi dưới tải trọng lớn, bên đặt giá thầu được chia thành 3 loại lớn:

Bên đặt giá thầu "phản hồi mọi thứ"

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

  • Khi tỷ lệ yêu cầu tăng lên, độ trễ yêu cầu cũng tăng theo, cho đến khi tất cả yêu cầu bắt đầu hết thời gian
  • Thời gian chờ tăng cao khi tỷ lệ chú thích đạt đến mức cao nhất
  • Điều tiết, giảm mạnh số lượng chú thích được phép
  • Độ trễ bắt đầu khôi phục, khiến điều tiết giảm
  • Chu kỳ sẽ bắt đầu lại.

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

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

Người đặ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ả lại lỗi cho một số chú thích. Bạn có thể thực hiện việc này thông qua 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ế độ giảm xác suất 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 thứ", bên đặt giá thầu này "cắt giảm số lỗ" để có thể khôi phục ngay khi giá yêu cầu giảm.

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

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

Bên đặt giá thầu này chấp nhận chú thích lên đến một mức giá nhất định, sau đó bắt đầu trả về các phản hồi "không đặt giá thầu" cho bất kỳ trường hợp quá tải nào. Tương tự như lỗi bên đặt giá thầu "lỗi về quá tải", lỗi này có thể được triển khai theo nhiều 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ờ điều tiết chú thích. Tình trạng quá tải được các máy giao diện người dùng hấp thụ, chỉ cho phép lưu lượng truy cập mà các máy này có thể xử lý để tiếp tục đến các phần phụ trợ.

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

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

  • Cấp phép quá mức cho các giao diện người dùng và đặt chúng thành lỗi khi quá tải, để giúp tối đa hoá số lượng kết nối mà các giao diện người dùng có thể phản hồi theo một dạng nào đó.
  • Khi gặp lỗi quá tải, các máy giao diện người dùng có thể sử dụng phản hồi "không đặt giá thầu" soạn trước và hoàn toàn không cần phân tích cú pháp yêu cầu.
  • Triển khai quy trình kiểm tra tình trạng của các phần phụ trợ để nếu không có đủ dung lượng, chúng sẽ trả về phản hồi "no-bid" (không đặt giá thầu).

Điều này cho phép một số phương thức nạp chồng được hấp thụ và giúp các phần phụ trợ có cơ hội phản hồi chính xác số lượng yêu cầu tối đa có thể xử lý. Bạn có thể coi đây là vấn đề "không đặt giá thầu khi quá tải", trong đó các máy giao diện người dùng 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 việc chuyển đổi bên đặt giá thầu đó thành bên đặt giá thầu "lỗi về quá tải" bằng cách điều chỉnh hành vi kết nối để từ chối tình trạng quá tải. Mặc dù có thể trả về nhiều lỗi hơn, nhưng phương thức này sẽ làm 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 trong khi không phải quản lý kết nối mỗi lần có ý nghĩa quan trọng đối với việc gỡ lỗi. Google sử dụng 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.v. Yêu cầu ping có dạng sau:

Google

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

JSON JSON

"id": "4YB27BCXimH5g7wB39nd3t"

OpenRTB Protobuf

id: "7xd2P2M7K32d7F7Y50p631"

Lưu ý rằng, trái ngược 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 nào. Ngoài ra, 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 với Google. Kết nối ngang hàng giúp tối ưu hoá lưu lượng truy cập đường dẫn để tiếp cận người đặ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 liên kết trung gian thay đổi. Hãy xem Hướng dẫn sử dụng tính năng ngang hàng để biết thông tin chi tiết. Sau đây là lý do bạn nên coi việc kết nối ngang hàng là một phương pháp hay nhất:

  • Trên Internet, đường liên kết chuyển tuyến được chọn chủ yếu thông qua tính năng "định tuyến khoai tây chiên". Phương pháp này sẽ 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 đến và định tuyến gói thông qua đường liên kết đó. Khi lưu lượng truy cập đi qua một phần trong đường trục thuộc sở hữu của một nhà cung cấp mà chúng tôi có nhiều kết nối ngang hàng, đường liên kết đã chọn có thể ở gần vị trí bắt đầu gói này. Ngoài điểm đó, chúng tôi không có quyền kiểm soát tuyến đường mà gói đ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ự quản khác (mạng) trong quá trình chuyển gói.

  • Ngược lại, khi có một thoả thuận ngang hàng trực tiếp, các gói sẽ luôn được gửi dọc theo một đường liên kết ngang hàng. Bất kể nguồn gốc của gói, gói này sẽ truyền tải qua những đường liên kết mà Google sở hữu hoặc thuê cho đến khi đến điểm kết nối ngang hàng dùng chung. Đây là điểm 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 chuyến ngắn để truy cập vào Mạng Google và tiếp tục ở trên Mạng Google cho đến hết chặng đường đó. Việc giữ lại hầu hết chuyến đi trên cơ sở hạ tầng do Google quản lý giúp đảm bảo gói đi theo lộ trình có độ trễ thấp và tránh được nhiều biến đổi 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.

Dưới đây là hai phương pháp phổ biến từ máy chủ DNS của bên đặt giá thầu khi cố gắng cân bằng tải hoặc quản lý khả năng cung cấp:

  1. Máy chủ DNS phát một địa chỉ hoặc một nhóm nhỏ địa chỉ để phản hồi truy vấn, sau đó xử lý 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 tập hợp địa chỉ, nhưng xoay vòng thứ tự các địa chỉ trong phản hồi.

Kỹ thuật đầu tiên là kém hiệu quả trong việc cân bằng tải vì có rất nhiều hoạt động lưu vào bộ nhớ đệm ở nhiều cấp độ trong ngăn xếp và việc cố gắng bỏ qua việc lưu vào bộ nhớ đệm có thể sẽ không nhận được kết quả như mong muốn vì Google sẽ 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 khả năng 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, do đó, thứ tự phản hồi là không quan trọng.

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