Sprawdzone metody dotyczące aplikacji RTB

W tym przewodniku znajdziesz sprawdzone metody, które warto wziąć pod uwagę podczas tworzenia aplikacji zgodnie z protokołem RTB.

Zarządzanie połączeniami

Podtrzymuj kontakty

Nawiązywanie nowego połączenia zwiększa opóźnienia i wymaga znacznie więcej zasobów po obu stronach niż ponowne użycie istniejącego połączenia. Przez zamknięcie mniejszej liczby możesz zmniejszyć liczbę wymaganych połączeń ponownie.

Po pierwsze, każde nowe połączenie wymaga dodatkowej wymiany danych z siecią. Ze względu na to, że nawiązujemy połączenia na żądanie, pierwsze żądanie ma krótszy termin i większe prawdopodobieństwo przekroczenia limitu czasu kolejnych żądań. Wszelkie dodatkowe limity czasu zwiększają liczbę błędów, co może prowadzić do ograniczenia licytującego.

Po drugie, wiele serwerów WWW tworzy specjalny wątek roboczy dla każdego połączenia. . Oznacza to, że aby zamknąć i ponownie utworzyć połączenie, serwer musi zamknąć i odrzucić wątek, przydzielić nowy, umożliwić jego uruchomienie i utworzyć stan połączenia, zanim przetworzy prośbę. To dużo niepotrzebnych nakładów pracy.

Unikaj zamykania połączeń

Zacznij od dostrajania działania połączenia. Większość domyślnych ustawień serwera jest dostosowana do środowisk z dużą liczbą klientów, z których każdy wysyła niewielką liczbę żądań. Z kolei w przypadku RTB niewielka pula komputerów wysyła żądania dla dużej liczby przeglądarek. W ramach tych , zalecane jest ponowne wykorzystywanie połączeń tak często, jak to możliwe. Śr zalecamy ustawienie:

• Czas bezczynności: 2,5 minuty.
• Maksymalna liczba żądań na połączenie do najwyższej możliwej wartości.
• Maksymalna liczba połączeń z najwyższą wartością możliwą do uzyskania pamięci RAM przy jednoczesnym sprawdzaniu, czy liczba połączeń nie zbliża się do niej zbyt mocno.

Na przykład na serwerze Apache obejmuje to ustawienie KeepAliveTimeout do 150, od MaxKeepAliveRequests do i MaxClients na wartość zależną od typu serwera.

Po dostosowaniu działania połączenia upewnij się też, że kod licytującego nie zamyka niepotrzebnie połączeń. Jeśli na przykład masz kod interfejsu, który zwraca domyślną wartość „no bid” (brak stawki). odpowiedź w przypadku zdarzenia backendu lub przekroczenia limitu czasu oczekiwania, upewnij się, że kod zwraca odpowiedź bez zamykania połączenia. Dzięki temu unikniesz sytuacji, w której w przypadku przeciążenia licytatora połączenia zaczynają się zamykać, a liczba limitów czasu rośnie, co powoduje ograniczenie działania licytatora.

Dbaj o zrównoważoną liczbę połączeń

Jeśli Authorized Buyers łączy się z serwerami licytującego przez serwer proxy, połączenia mogą z czasem stać się niezrównoważone Ponieważ znając tylko adres IP serwera proxy, nie można określić, który serwer licytującego otrzymuje poszczególne wywołania. Z czasem wraz z założeniem i zamknięciem Authorized Buyers ponowne uruchomienie serwerów licytującego, liczba połączeń mogą być bardzo zmienne.

Gdy niektóre połączenia są intensywnie wykorzystywane, inne otwarte połączenia mogą pozostawać w większości nieaktywne, ponieważ nie są w danym momencie potrzebne. Jako Zmiany w ruchu w Authorized Buyers oraz nieaktywne połączenia mogą stać się aktywne i aktywne połączenia mogą być nieaktywne. Jeśli połączenia są źle pogrupowane, mogą powodować nierówne obciążenie serwerów licytujących. Google stara się temu zapobiec, zamykając wszystkie połączenia po 10 tys. żądań, aby automatycznie wyrównywać na bieżąco połączenia z najczęściej używanymi adresami. Jeśli nadal widzisz nierówny rozkład ruchu w swoim środowisku, możesz podjąć dodatkowe działania:

1. Wybierz backend na żądanie, a nie raz na połączenie , jeśli korzystasz z serwerów proxy frontendu.
2. Jeśli łączysz się przez serwer proxy za pomocą sprzętowego równoważnika obciążenia lub zapory sieciowej, określ maksymalną liczbę żądań na połączenie. Po nawiązaniu połączeń mapowanie jest stałe. Pamiętaj, że Google określa już górny limit 10 tys. żądań na połączenie, więc musisz podać bardziej rygorystną wartość tylko wtedy, gdy w Twoim środowisku nadal występują liczne połączenia z takimi żądaniami. Na przykład w Apache ustaw wartość MaxKeepAliveRequests na 5000.
3. Skonfiguruj serwery licytującego tak, aby monitorowały częstotliwość żądań i zamykały niektóre własnych połączeń, jeśli systematycznie obsługuje zbyt wiele żądań. w porównaniu z konkurencją.

Eleganckie radzenie sobie z przeciążeniem

W idealnej sytuacji limity powinny być ustawione na tyle wysokie, aby licytujący mógł otrzymać wszystkie żądania, które może obsłużyć, ale nie więcej. W praktyce utrzymywanie limitów że optymalne poziomy są trudnym zadaniem i zdarzają się przeciążenia, Powodów: działanie backendu w godzinach szczytu, zestawienie ruchu zmieniające się w taki sposób, wymaga dodatkowego przetwarzania dla każdego żądania lub ustalenie wartości limitu jest za duża. Dlatego warto się zastanowić, jak licytujący zachowa się zbyt dużo ruchu.

W związku z tymczasowymi zmianami ruchu (do 1 tygodnia) między regionami (zwłaszcza między Azją a Zachodem Stanów Zjednoczonych oraz Stanami Zjednoczonymi wschodu i Zachodem Stanów Zjednoczonych), zalecamy zmniejszenie o 15% między szczytem sezonu z 7 dni a liczbą zapytań na sekundę na każdą transakcję. Lokalizacja.

Jeśli chodzi o zachowanie w przypadku dużych obciążeń, oferenci dzielą się na 3 szerokie kategorie:

Licytujący „odpowiedz na wszystko”

Ten licytujący jest łatwy do wdrożenia, ale jego wyniki są najsłabsze, gdy jest przeciążony. po prostu próbuje odpowiedzieć na każde otrzymane pytanie o stawkę, a nie ani dodawać do kolejki tych, których nie można udostępnić od razu. Scenariusz która często pojawia się w takiej sytuacji:

• Wraz ze wzrostem częstotliwości żądań rośnie czas oczekiwania na ich wykonanie, aż w końcu wszystkie żądania zaczynają się przerywać.
• Opóźnienia rosną gwałtownie, gdy współczynniki objaśnień zbliżają się do szczytu
• Włącza się ograniczanie, które znacznie zmniejsza liczbę dozwolonych wezwań
• Opóźnienia zaczynają się zmniejszać, co powoduje zredukowanie przepustowości
• Cykl zaczyna się od nowa.

Wykres opóźnienia dla tego licytującego przypomina bardzo stromy wzór zębatkowy. Z kolei żądania w kolejce powodują rozpoczęcie stronicowania przez serwer pamięci podręcznej lub wykonywania czegoś innego, co spowalnia długotrwałe opóźnienie, nie wróci do zdrowia do czasu zakończenia szczytu, co prowadzi do depresji i wywołania w całym okresie szczytu. W obu przypadkach liczba wywołań i liczba odpowiedzi jest mniejsza niż w przypadku ustawienia niższej wartości limitu.

Licytujący „error on overload”

Ten licytujący akceptuje objaśnienia do określonej stawki, a potem zaczyna zwracanie w niektórych objaśnieniach. Można to zrobić za pomocą wewnętrznych limitów czasowych, wyłączając kolejkowanie połączeń (sterowane przez parametr ListenBackLog w Apache), wdrażając tryb odrzucania z prawdopodobieństwem, gdy wykorzystanie lub opóźnienia stają się zbyt wysokie, lub stosując inny mechanizm. Jeśli odsetek błędów przekracza 15%, zaczniemy ich ograniczać. W przeciwieństwie do licytującego, który „odpowiada na wszystko”, ten licytujący „ogranicza straty”, co pozwala mu natychmiast odzyskać straty, gdy współczynniki zapytań spadają.

Wykres czasu oczekiwania w przypadku tego licytującego przypomina rysowanie piły. w przypadku przeciążeń, zlokalizowany wokół maksymalnej dopuszczalnej stawki.

Licytujący „brak stawki w przypadku przeciążenia”

Ten licytujący akceptuje objaśnienia do określonej stawki, a potem zaczyna zwracanie brak stawki odpowiedzi na wszelkie przeciążenia. Podobnie jak w przypadku oferentowania z opcją „error on overload” można to zaimplementować na kilka sposobów. Różnica polega na tym, że do Google nie jest zwracany żaden sygnał, więc nigdy nie ograniczamy liczby wywołań. Przeciążenie jest absorbowane przez maszyny front-endowe, które przepuszczają tylko ruch, który mogą obsłużyć, do backendów.

Wykres czasu oczekiwania dla tego licytującego pokazuje płaskowyż, który (sztucznie) przestaje równolegle do liczby żądań w godzinach szczytu, odsetek odpowiedzi zawierających stawkę.

Zalecamy połączenie atrybutu „błąd przy przeciążeniu” z funkcją „brak stawki w przypadku przeciążenia”, w następujący sposób:

• Przeskaluj interfejsy i ustaw je tak, aby w przypadku przeciążenia generowały błąd. Pomoże to zmaksymalizować liczbę połączeń, na które mogą one odpowiadać.
• W przypadku wystąpienia przeciążenia maszyny frontowe mogą użyć gotowego szablonu „no-bid” i nie muszą w ogóle analizować żądania.
• Zaimplementuj kontrolę stanu backendów, tak by w przypadku braku wystarczającej mocy obliczeniowej zwracały komunikat „no-bid” .

Dzięki temu można częściowo zniwelować przeciążenie i dać backendom możliwość odpowiedzi na dokładnie tyle żądań, ile są w stanie obsłużyć. Możesz to traktować jako „brak stawki przy przeciążeniu”, gdy maszyny front-end przechodzą w tryb „błąd przy przeciążeniu”, gdy liczba żądań jest znacznie większa niż oczekiwana.

Jeśli masz system licytujący „odpowiadaj na wszystko”, rozważ przekształcenie go w system licytujący „błąd na przekroczenie limitu”, dostosowując zachowanie połączenia tak, aby odmawiał obsługi zapytania. Chociaż powoduje to zwracanie większej liczby błędów, zmniejsza limit czasu oczekiwania i zapobiega przejściu serwera do stanu, w którym nie może odpowiadać na żadne żądania.

Odpowiadanie na pingi

Upewnienie się, że licytujący może odpowiadać na żądania ping, ale nie nawiązuj połączenia samo w sobie zarządzania jest zaskakująco ważne w przypadku debugowania. Google używa pingu żądania sprawdzenia poprawności i debugowania stanu licytującego, zamknięcie połączenia działanie aplikacji, czas oczekiwania itd. Żądania ping mają następującą formę:

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

Pamiętaj, że wbrew temu, czego można oczekiwać, żądanie ping nie zawiera żadnych boksy reklamowe. Zgodnie ze szczegółami powyżej nie zamykaj połączenia po udzieleniu odpowiedzi na żądanie ping.

Rozważ połączenia równorzędne

Innym sposobem na zmniejszenie opóźnień w sieci lub ich zmienności jest połączenie równorzędne z Google. Połączenie równorzędne pomaga zoptymalizować ścieżkę, jaką ruch kieruje ruch do systemu licytującego. punkty końcowe połączenia pozostają takie same, ale zmieniają się linki pośrednie. Zobacz Więcej informacji znajdziesz w przewodniku dotyczącym połączeń równorzędnych. Powód, dla którego peering jest sprawdzoną metodą, można podsumować w ten sposób:

• W internecie linki tranzytowe są wybierane głównie za pomocą „przekierowywania gorących ziemniaków”, które znajduje najbliższy link poza naszą siecią, który może przekazać pakiet do miejsca docelowego, i kieruje pakiet przez ten link. Gdy ruch przechodzi przez część sieci szkieletowej należącej do dostawcy, z którym mamy wiele połączeń peeringowych, wybrane połączenie będzie prawdopodobnie znajdować się w pobliżu miejsca, w którym zaczyna się pakiet. Poza tym nie mamy kontroli nad trasą przesyłania pakietu jest przekazywana do systemu licytującego, więc może być odsyłana do innych systemów autonomicznych (sieci).

• Gdy jednak istnieje umowa o bezpośrednim połączeniu, pakiety są zawsze wysyłane przez połączenie peeringowe. Niezależnie od tego, skąd pochodzi pakiet, przechodzi przez łącza należące do Google lub dzierżane przez tę firmę, aż do wspólnego punktu peeringu, który powinien znajdować się w pobliżu lokalizacji licytującego. Podróż w tył rozpoczyna się od krótkiego przeskoku do sieci Google i pozostaje w Google, w dalszej części sieci. Przechowywanie większości danych w infrastrukturze zarządzanej przez Google zapewnia, że pakiet będzie się przemieszczał po trasie o niskiej latencji i nie będzie narażony na duże wahania.

Prześlij statyczny DNS

Zalecamy kupującym, aby zawsze przesyłali do Google pojedynczy statyczny wynik DNS, w Google, aby obsługiwać przesyłanie ruchu.

Oto 2 popularne metody stosowane przez oferentów na serwerach DNS w celu wczytania nierównowagi lub zarządzania dostępnością:

1. Serwer DNS przekazuje w odpowiedzi jeden adres lub podzbiór adresów a następnie przejrzyj tę odpowiedź w określony sposób.
2. Serwer DNS zawsze odpowiada tym samym zbiorem adresów, ale cyklicznie kolejność adresów w odpowiedzi.

Pierwsza metoda jest słaba w równoważeniu obciążenia, ponieważ wiele poziomów stosu, a próba ominięcia buforowania prawdopodobnie nie będzie uzyskasz także preferowane wyniki, bo Google nalicza czas rozpoznawania nazw DNS licytującego.

Druga metoda w ogóle nie zapewnia równoważenia obciążenia, ponieważ Google losowo wybiera adres IP z listy odpowiedzi DNS, więc kolejność w odpowiedzi nie ma znaczenia.

Jeśli licytujący wprowadzi zmianę w DNS, Google będzie stosować wartość TTL (czas życia danych) ustawioną w rekordach DNS, ale interwał odświeżania pozostaje niepewny.