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 giúp tăng độ trễ và tốn nhiều công sức hơn ở cả hai đầu thay vì sử dụng lại một tài nguyên hiện có. Ẩn bớt kết nối, bạn có thể giảm số lượng kết nối phải mở một lần nữa.

Trước tiên, mỗi kết nối mới đòi hỏi một mạng bổ sung khứ hồi để 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. Nhiều lắm 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 với 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. Theo nên sử dụng lại kết nối càng nhiều lần càng tốt. T4 khuyên bạn nên đặt:

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

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 hành vi kết nối được điều chỉnh, 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ề 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 mà nếu bên đặt giá thầu của bạn nhận được quá tải, 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 của bạn bị điều tiết.

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

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, các kết nối có thể bị 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 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 đối tượng 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 đó. Như Các thay đổi về lưu lượng truy cập của Authorized Buyers, kết nối ở trạng thái rảnh có thể hoạt động kết nối có thể không hoạt động. Điều này có thể gây ra tải không đồng đều trên máy chủ của người đặt giá thầu của bạn nếu các kết nối bị nhóm kém. 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 tình trạng 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, đặ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ỷ lệ yêu cầu của họ và đóng một số nếu chúng liên tục xử lý quá nhiều yêu cầu so với những ứng dụng ngang hàng.

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ủa bạn có thể nhận được tất cả các yêu cầu mà nó có thể xử lý, nhưng không nhiều hơn thế. Trên thực tế, việc duy trì hạn mức ở mức cấp 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, đối với nhiều loại lý do: phần phụ trợ ngừng hoạt động trong thời gian cao điểm, tổ hợp lưu lượng truy cập thay đổi để phải xử lý nhiều hơn cho mỗi yêu cầu hoặc một giá trị hạn mức vừa đượ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 Á với 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 thường xảy 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ỳ 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 trong hàng đợi khiến máy chủ bắt đầu phân trang bộ nhớ hoặc thao tác nào khác có thể gây ra sự chậm trễ trong thời gian dài và độ trễ thì không thể khôi phục cho đến khi qua 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.

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

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. Việc này có thể được thực hiện thông qua thời gian chờ nội bộ, vô hiệu hoá vào hàng đợi 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 cao hoặc một 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 tổn thất," Nhờ đó, ngân hàng có thể 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 chú thích đến một tỷ lệ nhất định, sau đó bắt đầu trả về "no-bid" (không có giá thầu) phản hồi cho bất kỳ quá tải nào. Tương tự như "lỗi quá tải" bên đặt giá thầu, điều này có thể được triển khai theo nhiều 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ị không đổi (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 "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:

• Cấp phép cho giao diện người dùng quá mức và thiết lập lỗi khi quá tải nhằm giúp tối đa hoá số lượng kết nối mà giao diện người dùng có thể phản hồi ở dạng nào đó.
• Khi gặp lỗi về tình trạng quá tải, các máy giao diện người dùng có thể sử dụng lệnh "no-bid" (không có giá thầu) được soạn trước 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ợ, để 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ố phương thức nạp chồng và tạo cơ hội cho phần phụ trợ phản hồi chính xác nhiều yêu cầu nhất có thể. 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 thấy nút "Phản hồi cho mọi thứ" hãy xem xét việc chuyển đổi công cụ này thành "lỗi quá tải" bên đặt giá thầu bằng cách điều chỉnh hành vi kết nối để hành vi đó có hiệu lực từ chối bị quá tải. Mặc dù phương thức này gây ra nhiều lỗi hơn được trả về, giảm thời gian chờ và ngăn không cho 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 các lệnh ping

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

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

"id": "4YB27BCXimH5g7wB39nd3t"

id: "7xd2P2M7K32d7F7Y50p631"

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 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 ngang hàng giúp tối ưu hoá đường dẫn lưu lượng truy cập để đến được 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 các đườ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. Chiến lược phát hành đĩa đơn có thể tóm tắt lý do cho việc sử dụng 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 phương tiện công cộng chủ yếu được chọn thông qua loại từ khoá "hot-potato" định tuyến," tìm thấy liên kết gần nhất bên ngoài mạng của chúng tôi mà có thể nhận được gói tin đến đích rồi định tuyến gói tin qua 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 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, truyền tải các liên kết mà Google sở hữu hoặc cho thuê cho đến khi truy cập được vào điểm ngang hàng. Đ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 ngắn vào mạng Google và tiếp tục có mặt trên Google mạng trong suốt quá trình. Phần lớn chuyến đi do Google quản lý cơ sở hạ tầng đảm bảo gói đi theo tuyến có độ trễ thấp và tránh được có thể có nhiều biến động.

Gửi DNS tĩnh

Chúng tôi khuyên người mua luôn gửi một kết quả DNS tĩnh duy nhất cho Google và dựa vào trên 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 của bên đặt giá thầu Máy chủ DNS khi đang cố gắng tải số dư hoặc quản lý tính sẵn có:

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 theo chu kỳ thứ tự của địa chỉ trong phản hồi.

Kỹ thuật đầu tiên kém hiệu quả trong việc cân bằng tải vì có rất nhiều bộ nhớ đệm tại nhiều cấp độ của ngăn xếp và các nỗ lực bỏ qua việc lưu vào bộ nhớ đệm sẽ không bạn sẽ nhận được kết quả mong muốn vì Google sẽ tính phí thời gian phân giải DNS vào 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 thực hiện 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 chưa chắc chắn.