Sprawdzone metody dotyczące aplikacji RTB

Ten przewodnik wyjaśnia sprawdzone metody, o których warto pamiętać podczas tworzenia aplikacji zgodnie z protokołem RTB.

Zarządzanie połączeniami

Podtrzymuj kontakty

Nawiązanie nowego połączenia wydłuża czas oczekiwania i wymaga znacznie więcej pracy na dwa sposoby, niż na ponowne wykorzystanie tych, które już masz. Przez zamknięcie mniejszej liczby możesz zmniejszyć liczbę wymaganych połączeń ponownie.

Po pierwsze, każde nowe połączenie wymaga dodatkowej wymiany danych ustanawiać. 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 zakończyć i odtworzyć połączenie, serwer muszą zostać zamknięte i odrzucić wątek, przydzielić nowy i uruchomić go; tworzyć stan połączenia przed ostatecznym przetworzeniem żądania. 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 z dużą liczbą klientów, z których każde wymaga niewielkiej liczby żądań. Z kolei w przypadku RTB niewielka pula komputerów wysyła żądania dla dużej liczby przeglądarek. W ramach tych , staraj się robić to jak najwięcej razy. Śr zalecamy ustawienie:

• Czas oczekiwania przy bezczynności do 2,5 minuty.
• Maksymalna liczba żądań w połączeniu z najwyższym 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 system licytujący przeciążenie, połączenia zaczynają się zamykać i zwiększa się liczba przekroczeń limitu czasu i ograniczało możliwości licytującego.

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ą w większości pozostają bezczynne, ponieważ w tej chwili nie są potrzebne. Jako Zmiany w ruchu w Authorized Buyers oraz nieaktywne połączenia mogą stać się aktywne i aktywne połączenia mogą być nieaktywne. Może to powodować nierównomierne obciążenia serwerów licytującego jeśli połączenia są słabo ułożone. Google próbuje temu zapobiec poprzez: zamykanie wszystkich połączeń po wysłaniu 10 000 żądań w celu automatycznego zrównoważenia temperatury połączeń w czasie. Jeśli nadal będzie brakować zrównoważonego ruchu na stronie możesz podjąć następujące działania:

1. Wybierz backend na żądanie, a nie raz na połączenie , jeśli korzystasz z serwerów proxy frontendu.
2. Określ maksymalną liczbę żądań na połączenie, jeśli korzystasz przez serwer proxy, przez sprzętowy system równoważenia obciążenia lub zaporę sieciową, po nawiązaniu połączeń zostaje ustalone mapowanie. Pamiętaj, że Google ma już określony górny limit 10 000 żądań na połączenie, bardziej rygorystyczną wartość musisz podać tylko wtedy, gdy nadal jest w środowisku, w którym połączenia stają się klastrowane. Na przykład w Apache ustaw 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ą.

Radź sobie z przeciążeniem

W idealnej sytuacji limity powinny być ustawione na tyle wysokie, aby licytujący mógł otrzymywać wszystkie dane, które może obsłużyć, ale nie tylko. 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 przy dużym obciążeniu, licytujący dzielą się na 3 ogólne kategorie:

Funkcja „odpowiadaj na wszystko” licytujący

Chociaż jest to proste, system licytujący uzyskuje najniższą skuteczność, przeciążona. po prostu próbuje odpowiedzieć na każde otrzymane pytanie o stawkę, a nie ani dodawać do kolejki tych, które nie mogą zostać udostępnione od razu. Scenariusz która często pojawia się w takiej sytuacji:

• Wraz ze wzrostem częstotliwości żądań rosną czasy oczekiwania, aż wszystkie żądania przekroczenie limitu czasu oczekiwania
• Opóźnienia rosną gwałtownie, gdy współczynniki objaśnień zbliżają się do szczytu
• Rozpoczęło się ograniczanie, znacząco zmniejszając liczbę dozwolonych wywołań
• Opóźnienia zaczynają się zmniejszać, co powoduje zredukowanie przepustowości
• Cykl zaczyna się od nowa.

Wykres czasu oczekiwania tego licytującego przypomina bardzo stromy ząb piły wzorcem. 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 tworzonych jest mniej objaśnień lub na odpowiedź, jeśli limit został po prostu ustawiony na niższy.

„Błąd przy przeciążeniu” licytujący

Ten licytujący akceptuje objaśnienia do określonej stawki, a potem zaczyna zwracanie w niektórych objaśnieniach. Mogą to być wewnętrzne limity czasu, wyłączenie kolejkowanie połączeń (kontrolowane przez ListenBackLog w Apache), wdrożenie trybu prawdopodobieństwa utraty danych, gdy wykorzystanie lub czas oczekiwania rośnie lub wykorzystując inny mechanizm. Jeśli odsetek błędów przekracza 15%, zaczniemy ich ograniczać. W przeciwieństwie do opcji „Odpowiadaj na wszystko” licytujący, ten licytujący „zmniejsza straty”, co pozwala na jej przywrócenie natychmiast po spadku częstotliwości żądań. w dół.

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

Błąd „brak stawki w przypadku przeciążenia” licytujący

Ten licytujący akceptuje objaśnienia do określonej stawki, a potem zaczyna zwracanie brak stawki odpowiedzi na wszelkie przeciążenia. Sytuacja podobna do „błędu przy przeciążeniu” licytującego można go wdrożyć na wiele sposobów. Różnica polega na tym, do Google jest zwracany sygnał, więc nigdy nie ograniczamy wywołań. przeciążenie jest absorbowane przez maszyny frontendu, które dopuszczają wyłącznie aby mógł przechodzić 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:

• Zapewnij nadmiarowe zasoby dla interfejsów i ustaw je na błędy w przypadku przeciążenia, aby zmaksymalizować liczbę połączeń, na które mogą odpowiedzieć w określonej formie.
• W przypadku wystąpienia przeciążenia maszyny frontowe mogą użyć gotowego szablonu „no-bid” i nie muszą w ogóle analizować żądania.
• Zaimplementować kontrolę stanu backendów, tak by w przypadku braku wystarczającej mocy obliczeniowej zwracały komunikat „no-bid” .

Umożliwia to absorbowanie części przeciążeń i daje backendom szansę odpowiadać na dokładnie tyle żądań, ile są w stanie obsłużyć. Możesz na przykład jako „brak stawki w przypadku przeciążenia”. gdy komputery frontendowe powracają do stanu „błąd włączony”, przeciążenie” gdy liczba żądań jest znacznie wyższa od oczekiwanej.

Jeśli używasz opcji „odpowiadasz na wszystko” licytującego, zastanów się nad przekształceniem go w „błąd przy przeciążeniu” systemu licytującego przez dostrajanie zachowania połączenia, nie chce być przeciążonym. 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ów mają taką postać:

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"

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łączenie równorzędne

Innym sposobem na zmniejszenie opóźnień lub zmienności sieci jest stosowanie połączeń równorzędnych 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. powody, dla których warto traktować połączenia równorzędne jako sprawdzoną metodę, można podsumować w następujący sposób:

• W internecie linki do transportu publicznego są wybierane głównie przez „gotowe ziemniaki” kierowanie ruchu”, który znajduje najbliższy link poza naszą siecią, który może pobrać do miejsca docelowego i kieruje pakiet przez ten link. Kiedy ruch przechodzi przez sekcję szkieletową należącą do dostawcy, z którym połączeń równorzędnych, wybrany link prawdopodobnie znajduje się blisko miejsca, pakietów startowych. 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).

• W przeciwieństwie do tego, gdy istnieje bezpośrednia umowa na połączenie równorzędne, pakiety są zawsze wysyłane razem z linkiem równorzędnym. Niezależnie od tego, skąd pochodzi pakiet, przemierza linki będące własnością Google lub dzierżawione przez Google, aż trafi do udostępnionych 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. Większość podróży jest zarządzana przez Google Infrastruktura zapewnia, że pakiet korzysta z trasy z krótkim czasem oczekiwania oraz omija o dużej potencjalnej zmienności.

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 typowe metody stosowane przez systemy licytujące Serwery DNS podczas próby wczytania lub zarządzaj 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 zestawem 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 możesz też otrzymać preferowane wyniki, bo Google nalicza czas rozpoznawania nazw DNS licytującego.

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

Jeśli licytujący wprowadzi zmianę w systemie DNS, Google uwzględni wartość TTL(czasu życia) ustawione w rekordach DNS, ale interwał odświeżania pozostaje niepewny.