Best practice per applicazioni RTB

Questa guida illustra le best practice da tenere presenti durante lo sviluppo di applicazioni secondo il protocollo RTB.

Gestire le connessioni

Mantieni attive le connessioni

Stabilire una nuova connessione aumenta le latenze e richiede molto di più le risorse da entrambi i lati rispetto al riutilizzo di una esistente. Chiudendo meno puoi ridurre il numero di connessioni da aprire di nuovo.

Innanzitutto, ogni nuova connessione richiede un round-trip di rete aggiuntivo per stabilire. Dal momento che stabiliamo connessioni on demand, la prima richiesta ha una scadenza effettiva più breve e ha maggiori probabilità di scadere richieste successive. Eventuali timeout aggiuntivi aumentano il tasso di errore, generando alla limitazione dello strumento di offerta.

In secondo luogo, molti server web generano un thread worker dedicato per ogni connessione. la creazione di un progetto. Ciò significa che per chiudere e ricreare la connessione, il server deve arrestare e ignorare un thread, assegnarne uno nuovo, renderlo eseguibile e lo stato della connessione prima di elaborare ultimamente la richiesta. Sono tante di costi non necessari.

Evita di chiudere le connessioni

Inizia ottimizzando il comportamento della connessione. La maggior parte delle impostazioni predefinite del server è personalizzata ambienti con un gran numero di clienti, ognuno dei quali esegue un richieste. Per RTB, al contrario, un piccolo pool di macchine invia richieste per conto di un gran numero di browser. Sotto questi ha senso riutilizzare le connessioni il più possibile. Me di impostare:

• Timeout per inattività a 2,5 minuti.
• Numero massimo di richieste su una connessione all'istanza valore possibile.
• Numero massimo di connessioni al valore massimo possibile per la RAM pur mantenendo il numero di connessioni non si avvicina troppo a quel valore.

In Apache, ad esempio, ciò comporta l'impostazione Da KeepAliveTimeout a 150, da MaxKeepAliveRequests a zero e MaxClients a un valore che dipende dal tipo di server.

Una volta ottimizzato il comportamento della connessione, devi assicurarti anche che il codice dello strumento di offerta non chiude inutilmente le connessioni. Ad esempio, se disponi codice front-end che restituisce l'impostazione predefinita "Nessuna offerta" in caso di backend errori o timeout, assicurati che il codice restituisca la sua risposta senza chiudere il connessione. In questo modo, eviterai la situazione in cui, se l'offerente ottiene sovraccarico, le connessioni iniziano a chiudersi e il numero di timeout aumenta. causando la limitazione dello strumento di offerta.

Mantieni un equilibrio delle connessioni

Se Authorized Buyers si connette ai server del tuo strumento di offerta attraverso un server proxy, le connessioni potrebbero risultare sbilanciate nel tempo poiché conoscendo solo l'indirizzo IP del server proxy, Authorized Buyers non è in grado di determinare quale server dello strumento di offerta riceve ciascun callout. Nel tempo, man mano che Authorized Buyers stabilisce e chiude di connessioni e server dell'offerente riavviati, il numero di connessioni mappati a ciascuno può diventare molto variabile.

Quando alcune connessioni sono molto utilizzate, altre connessioni aperte potrebbero rimangono in gran parte inattivi perché non sono necessari in quel momento. Come Cambiamenti del traffico di Authorized Buyers e le connessioni inattive possono diventare attive e attive le connessioni possono rimanere inattive. Potrebbero causare caricamenti non uniformi sui server degli offerenti se le connessioni sono in cluster in modo scadente. Google tenta di evitarlo chiudendo tutte le connessioni dopo 10.000 richieste, per ribilanciare automaticamente connessioni nel tempo. Se noti che il traffico continua a essere sbilanciato nella tua puoi seguire altri passaggi:

1. Seleziona il backend per richiesta anziché una volta per connessione se utilizzi proxy frontend.
2. Specifica un numero massimo di richieste per connessione se il proxy delle connessioni attraverso un bilanciatore del carico hardware o un firewall il mapping è fisso una volta stabilite le connessioni. Tieni presente che Google specifica già un limite massimo di 10.000 richieste per connessione, dovresti fornire un valore più restrittivo solo se trovi di connessioni in cluster nel tuo ambiente. In Apache, ad esempio, imposta MaxKeepAliveRequests su 5000
3. Configura i server dell'offerente in modo da monitorare i tassi di richieste e chiudere alcune delle loro connessioni se gestiscono costantemente troppe richieste rispetto ai loro colleghi.

Gestisci il sovraccarico con eleganza

Idealmente, le quote dovrebbero essere impostate su un valore sufficientemente elevato da consentire allo strumento di offerta di ricevere tutte le richieste che è in grado di gestire, ma non di più. In pratica, mantenere le quote di mantenere i livelli ottimali è un compito difficile e si verificano sovraccarichi, per una varietà di motivi: un backend che si arresta durante le ore di punta, una combinazione di traffico che cambia in modo che è necessaria una maggiore elaborazione per ogni richiesta oppure è appena stato impostato un valore di quota troppo alto. Di conseguenza, vale la pena valutare il comportamento dello strumento di offerta perché il traffico in entrata è eccessivo.

Per far fronte a variazioni temporanee del traffico (fino a una settimana) tra regioni (soprattutto tra Asia e Stati Uniti occidentali e Stati Uniti orientali e Stati Uniti occidentali), consigliamo un cuscino del 15% tra il picco di 7 giorni e il QPS per trading Posizione.

In termini di comportamento sotto carico, gli offerenti rientrano in tre categorie categorie:

La "risposta a tutto" offerente

Sebbene sia facile da implementare, questo offerente è il peggiore sovraccarico. Cerca semplicemente di rispondere a ogni richiesta di offerta in arrivo, , mettendo in coda quelli che non possono essere pubblicati immediatamente. Lo scenario che ne consegue è spesso qualcosa di simile:

• Se la percentuale di richieste aumenta, aumentano anche le latenze delle richieste, finché tutte le richieste avvio del timeout
• Le latenze aumentano vertiginosamente man mano che i tassi di callout si avvicinano al picco
• Viene applicata la limitazione, che riduce drasticamente il numero di callout consentiti
• Le latenze iniziano a recuperare, con una conseguente riduzione della limitazione
• Il ciclo da ricomincia.

Il grafico della latenza per questo offerente assomiglia a un dente di sega molto ripido pattern. In alternativa, le richieste in coda causano l'avvio del paging da parte del server la memoria o fare qualcos'altro che causi un rallentamento a lungo termine, mentre le latenze non recuperano fino al termine dei momenti di picco, con conseguente abbassamento dei callout percentuali durante l'intero periodo di picco. In entrambi i casi, vengono effettuati meno callout o rispetto a quanto accadrebbe se la quota fosse stata semplicemente impostata su un valore inferiore.

"Errore in caso di sovraccarico" offerente

Questo offerente accetta callout fino a una determinata tariffa, poi inizia a restituire errori per alcuni callout. Questa operazione può essere eseguita tramite timeout interni, disattivando accodamento delle connessioni (controllato da ListenBackLog su Apache), implementazione di una modalità di caduta probabilistica quando si applicano anche casi di utilizzo o latenze alta o con un altro meccanismo. Se Google osserva un tasso di errore superiore al 15%, inizieremo a limitare le risorse. A differenza della "risposta a tutto" offerente, questo offerente "taglia le sue perdite", che gli consente di recuperare immediatamente quando i tassi di richieste vanno a buon fine verso il basso.

Il grafico della latenza per questo offerente assomiglia a un dente di sega superficiale durante i sovraccarichi, localizzato attorno al limite massimo accettabile di conversione.

L'opzione "Nessuna offerta in caso di sovraccarico" offerente

Questo offerente accetta callout fino a una determinata tariffa, poi inizia a restituire "nessuna offerta" risposte per qualsiasi sovraccarico. Simile a "Errore relativo al sovraccarico" offerente, questo può essere implementato in vari modi. La differenza qui è che no vengono restituiti a Google, pertanto non riduciamo mai le limitazioni dei callout. La il sovraccarico viene assorbito dalle macchine front-end, che consentono solo il traffico che è in grado di gestire per raggiungere i backend.

Il grafico della latenza per questo offerente mostra un picco che (in modo artificiale) interrompe il parallelismo della frequenza di richieste nei momenti di picco e un corrispondente calo la frazione di risposte che contengono un'offerta.

Consigliamo di combinare l'errore "Errore relativo al sovraccarico" con l'espressione "no-bid on overload" nel seguente modo:

• Esegui l'overprovisioning dei front-end e impostali su un errore in caso di sovraccarico, in modo da massimizzare il numero di connessioni a cui possono rispondere in un determinato formato.
• Quando si verificano errori in caso di sovraccarico, le macchine front-end possono utilizzare un'istruzione predefinita "no-bid" e non hanno bisogno di analizzare la richiesta.
• Implementare il controllo di integrità dei backend, in modo che, se nessuno dispone di capacità sufficiente, restituisca un errore "no-bid" la risposta corretta.

Ciò consente di assorbire un certo sovraccarico e offre ai backend la possibilità di a rispondere esattamente a quante più richieste possono gestire. Puoi pensare a questo "Nessuna offerta in caso di sovraccarico" con macchine front-end che ritornano a "errori "sovraccarichi" quando il numero di richieste è significativamente più elevato del previsto.

Se hai una "risposta a tutto" offerente, valuta la possibilità di trasformarlo viene visualizzato un "errore di sovraccarico" lo strumento di offerta regolando il comportamento della connessione in modo che venga applicato rifiuta di essere sovraccaricate. Sebbene in questo modo vengano restituiti più errori, riduce i timeout e impedisce che il server entri in uno stato in cui non possono rispondere ad alcuna richiesta.

Rispondi ai ping

Assicurarsi che l'offerente possa rispondere alle richieste di ping senza connettersi della gestione di per sé, è sorprendentemente importante per il debug. Google utilizza ping richieste di controllo dello stato di integrità e debug dello stato dell'offerente, connessione chiusa comportamento, latenza e altro ancora. Le richieste di ping hanno il seguente formato:

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"

Tieni presente che, contrariamente a quanto ci si potrebbe aspettare, la richiesta ping non contiene aree annuncio. Inoltre, come descritto in precedenza, non devi chiudere la connessione dopo aver risposto a una richiesta di ping.

Valuta il peering

Un altro modo per ridurre la latenza o la variabilità della rete è eseguire il peering con Google. Il peering consente di ottimizzare il percorso seguito dal traffico per raggiungere lo strumento di offerta. La gli endpoint di connessione restano gli stessi, ma i collegamenti intermedi cambiano. Consulta le Guida ai peer per maggiori dettagli. La ragione per considerare il peering come una best practice può essere riassunto come segue:

• Su internet, i link al trasporto pubblico vengono scelti principalmente attraverso routing" che trova il link più vicino al di fuori della nostra rete che può ricevere un pacchetto alla sua destinazione e instradalo attraverso quel link. Quando il traffico attraversa una sezione di backbone di proprietà di un provider con cui abbiamo molte connessioni in peering, è probabile che il link scelto sia vicino al punto durante l'avvio del pacchetto. Dopodiché non abbiamo alcun controllo del routing del pacchetto segue all'offerente, quindi potrebbe essere rimandato ad altri sistemi autonomi (reti) lungo il percorso.

• Al contrario, quando è in atto un accordo di peering diretto, i pacchetti vengono viene sempre inviato insieme a un link di peering. Indipendentemente da dove ha origine il pacchetto, attraversa i link di proprietà o noleggiati da Google fino a raggiungere i punto di peering, che dovrebbe essere vicino alla località dell'offerente. Il percorso inverso inizia con un breve passaggio alla rete Google e rimane nella piattaforma Google rete per il resto del percorso. Mantenere la maggior parte del viaggio con gli strumenti gestiti da Google infrastruttura assicura che il pacchetto prenda una route a bassa latenza ed evita molta variabilità potenziale.

Invia DNS statico

Consigliamo agli acquirenti di inviare sempre un singolo risultato DNS statico a Google e di affidarsi su Google per gestire la distribuzione del traffico.

Ecco due pratiche comuni degli offerenti Server DNS durante il tentativo di caricamento bilanciare o gestire la disponibilità:

1. Il server DNS distribuisce in risposta un indirizzo o un sottoinsieme di indirizzi a una query, per poi scorrere la risposta in qualche modo.
2. Il server DNS risponde sempre con lo stesso insieme di indirizzi, ma cicli l'ordine degli indirizzi nella risposta.

La prima tecnica è scadente nel bilanciamento del carico poiché c'è molta memorizzazione nella cache da più livelli dello stack e i tentativi di aggirare la memorizzazione nella cache probabilmente ottenere anche i risultati preferiti, poiché Google addebita i tempi di risoluzione DNS offerente.

La seconda tecnica non consente di raggiungere il bilanciamento del carico poiché Google seleziona in modo casuale un indirizzo IP dall'elenco di risposte DNS, in modo che l'ordine la risposta non ha importanza.

Se un offerente apporta una modifica al DNS, Google rispetterà la durata(TTL) impostata impostato nei propri record DNS, ma l'intervallo di aggiornamento rimane incerto.