Migliorare le prestazioni della nostra tecnologia a vantaggio dei nostri clienti e del loro pubblico è una linea di condotta costante presso Verizon Media, ora Edgio. Ad esempio, negli ultimi due anni, i nostri ingegneri delle prestazioni e del kernel hanno eliminato praticamente tutte le cadute di pacchetti (oltre il 98% rimosso), migliorato i controlli dello stato delle prestazioni sui nostri edge server del 50% e aumentato la capacità dei server fino al 40%.
Abbiamo anche accoppiato quanto sopra con l’automazione di rete e l’espansione di rete organica – attualmente oltre 250 Tbps – per migliorare l’esperienza utente. La messa a punto delle nostre prestazioni ha svolto un ruolo importante nella nostra capacità di supportare picchi di rete in rapida evoluzione e talvolta imprevedibili, poiché forniamo aggiornamenti software per milioni di console di gioco, flussi video live per i principali eventi sportivi e quando i bilanciatori di carico multi-CDN trasferiscono il carico sulla nostra rete.
Mantenere la qualità su vasta scala implica l’ottimizzazione delle prestazioni in ogni parte dello stack tecnologico di Edgio Media Platform: Dai livelli inferiori, alla CPU e alla scheda di rete, fino al sistema operativo e alle applicazioni. In definitiva, il nostro obiettivo è sempre lo stesso: Grandi prestazioni. Per raggiungere questo obiettivo, eseguiamo analisi basate sui dati, basandoci su modifiche misurabili delle prestazioni per convalidare il nostro processo decisionale.
Ottimizzazioni della cache della CPU
Gestiamo 20.000 server in tutto il mondo, in gran parte chipset Broadwell e Haswell, con una media di 32 – 40 core. Abbiamo aggiunto 12.000 server solo negli ultimi tre anni. Tuttavia, la maggior parte dei server non è ottimizzata per scalare i carichi di lavoro già pronti all’uso. La semplice aggiunta di più server non rende il funzionamento più efficiente e può creare ulteriori sfide. Una scalabilità efficace richiede un’attenta ottimizzazione dei componenti esistenti. Essere in grado di ottimizzare un server in modo che sia in grado di elaborare due o tre volte (o più) le richieste rispetto alla configurazione predefinita può fare una notevole differenza per le prestazioni complessive della rete.
Il passaggio dallo snoop precoce allo snoop domestico
Le CPU moderne utilizzano un protocollo snoop per garantire che la cache della CPU locale sia coerente con la memoria. Ciò consente alle cache di ascoltare le modifiche alle variabili su qualsiasi CPU e di aggiornare le loro versioni di tali variabili di conseguenza. Non sorprende che la particolare tecnica utilizzata possa influire in modo significativo sulle prestazioni della memoria.
Per impostazione predefinita, i nostri fornitori di hardware utilizzano un protocollo chiamato Early Snoop. Ha una latenza inferiore per risolvere la coerenza della cache, poiché tutti i core possono effettuare richieste di coerenza della cache simultaneamente e inviare trasmissioni. Abbiamo riscontrato che i nostri sistemi generano quantità elevate di attività simultanee di disco e NIC durante gli scenari di picco di carico. Queste attività causano trasmissioni snoop elevate, con conseguenti colli di bottiglia nelle comunicazioni. Ciò causa il rallentamento del dispositivo di i/o e può portare a un arresto completo dell’elaborazione.
Passando alla modalità Home Snoop, un approccio che coalesca le richieste snoop, abbiamo assistito a una significativa riduzione del traffico broadcast. La Quick Path Interconnect (QPI) del processore non è più affamata durante i periodi di operazioni di i/o su disco e di rete; inoltre, le cadute di pacchetti che abbiamo visto con Early Snoop hanno ridotto significativamente il numero.
La modifica del protocollo snoop dipende semplicemente dalla modifica di un’impostazione del BIOS. Tuttavia, il riavvio di 20.000 server senza interrompere i clienti richiede automazione. Possiamo far funzionare questo tipo di modifiche di distribuzione su larga scala in produzione, in parte grazie alla nostra piattaforma di automazione IT basata su StackStorm, Crayfish.
Un evento di failover imprevisto
Durante il test del passaggio a Home Snoop, si è verificato un failover: Uno dei nostri maggiori clienti multimediali, che ha una distribuzione multi-CDN , ha riscontrato un problema con un altro fornitore e ha trasferito una parte significativa del loro traffico alla nostra CDN. Questo ha offerto l’opportunità di testare i miglioramenti su larga scala di Home Snoop, che hanno avuto un impatto estremamente significativo.
La figura precedente mostra l’effetto della modifica. Il gruppo che ancora utilizzava Early Snoop ha visto un aumento delle cadute di 13,75x (55 gocce di pacchetti per server al giorno), mentre il gruppo che era passato a Home Snoop ha visto un aumento di soli volte (27 gocce di pacchetti per macchina al giorno). Home Snoop ha immediatamente dimostrato il suo valore durante l’evento di failover.
Ottimizzazione dell’interfaccia di rete e sintonizzazione dei driver
Un altro importante set di ottimizzazione delle prestazioni riguardava l’interfaccia di rete e il driver. Qui, ci siamo concentrati sulla riduzione delle gocce di pacchetti che solitamente si verificano con il traffico burst. Durante gli eventi di grandi dimensioni, il traffico in entrata era così pesante che la scheda di interfaccia di rete non riusciva a tenere il passo, e abbiamo visto il rilascio dei pacchetti prima del previsto. Mentre abbiamo approfondito il motivo, abbiamo trovato diversi parametri sulla scheda di rete stessa da regolare, tra cui il numero di code, la dimensione della coda e la pianificazione degli interrupt. Per ottimizzare queste specifiche per il nostro particolare carico di lavoro e la nostra configurazione hardware, ci siamo concentrati sull’ottimizzazione del Receive Side Scaling (RSS) rendendo più lunghe le code in entrata, riducendo il loro numero complessivo e bilanciando gli interrupt tra i nodi NUMA.
Il grafico sopra mostra un test eseguito in Nord America, in cui ogni POP è diviso in un gruppo di controllo (cioè non sintonizzato) e un gruppo di test (cioè sintonizzato). Qui presentiamo il numero di gocce sommate ogni giorno in una settimana. A seguito delle sintonizzazioni, il nostro gruppo di test ha registrato circa il 95% in meno di gocce di pacchetti rispetto al gruppo di controllo, consentendo di elaborare un numero notevolmente maggiore di richieste. Ciò significa anche che è necessaria meno azione per gestire manualmente lo stato di salute della rete durante i picchi, lasciando i nostri ingegneri liberi di concentrarsi su altre aree.
Programmazione delle sintonizzazioni CPU
Mentre l’ottimizzazione del livello di driver e NIC si è concentrata sul miglioramento della capacità totale che possiamo offrire, le ottimizzazioni di pianificazione della CPU si sono concentrate sul miglioramento della coerenza con cui possiamo distribuire i contenuti.
Senza queste sintonizzazioni, i messaggi in entrata e in uscita devono competere per le risorse. Quando abbiamo iniziato a indagare sulla causa principale, abbiamo scoperto che il conflitto sulle risorse era dovuto al modo in cui il kernel pianificava la gestione di questi messaggi. Ciò significa che il carico non è stato migrato durante il picco di traffico fino a quando le CPU in questione sono state saturate. Per risolvere questo problema, impostiamo l’affinità della CPU dei processi del server Web in modo da escludere le CPU dedicate all’elaborazione del traffico di rete in entrata.
I grafici sopra riportati mostrano l’impatto dell’attivazione delle sintonizzazioni di pianificazione della CPU a livello globale sulla CDN dal 21 al 22 marzo. La Corte valuta l’impatto sulla base del 95o percentile e dei valori mediani di una metrica di controllo dello stato delle prestazioni, una metrica composita che dimostra il tempo di risposta relativo di un server. Come previsto, le valli a basso traffico non sono state significativamente ridotte; tuttavia, i picchi rivelano una significativa riduzione del conflitto tra traffico in entrata e in uscita. Ciò si traduce in un notevole miglioramento sia degli estremi che delle mediane, in particolare durante i picchi di carico. Ora siamo in grado di gestire meglio i picchi di traffico e risolvere i problemi legati a comportamenti anomali, come il rebuffer nei flussi video o la reattività complessiva di un server per tutti gli utenti.
Aggiornamenti delle prestazioni del kernel
Ottimizzare gli strati superiori del nostro stack tecnologico è importante quanto regolare gli elementi del livello inferiore. Nel corso dell’aggiornamento recente del nostro sistema operativo, abbiamo anche aggiornato i kernel Linux per trarre vantaggio dal lavoro di progettazione a monte della comunità del kernel Linux. Il nuovo kernel ha avuto circa quattro anni di sviluppo oltre alla versione precedente distribuita, inclusi miglioramenti al sistema di gestione della memoria, che riduce le allocazioni delle pagine bloccate e migliora la distribuzione del carico e le prestazioni quando si utilizza l’API di epoll e la condivisione dei socket.
Nel grafico sopra riportato, è possibile vedere l’effetto del processo di aggiornamento da fine novembre a inizio gennaio come un calo dei controlli di stato delle prestazioni del 99° percentile. I miglioramenti del kernel alla base hanno portato a una distribuzione del carico più uniforme su tutti i nostri processori di richiesta dei server Web. Ciò ha comportato un calo sostanziale di questi valori anomali, rendendo le richieste di tutti i nostri clienti più affidabili.
La regolazione delle prestazioni ha un effetto significativo
Negli ultimi due anni, le ampie ottimizzazioni dei sistemi implementate dall’ingegneria del kernel e delle prestazioni hanno eliminato virtualmente tutte le cadute di pacchetti (oltre il 98% rimosse) e dimezzato i controlli di stato delle prestazioni sui nostri edge server. La capacità dei nostri server è aumentata del 10-40% (la quantità esatta varia in base al profilo del cliente e all’evento), consentendoci di distribuire più traffico più velocemente. Il comportamento anomalo è migliorato in modo significativo, rendendo l’esperienza più coerente, e abbiamo notato un buon miglioramento sulle mediane, in particolare durante i picchi di carico. In sintesi, l’ottimizzazione delle prestazioni per l’intero stack tecnologico ci ha consentito di gestire meglio eventuali picchi di traffico imprevisti (sia che si tratti di un attesissimo aggiornamento della console di gioco o di un evento live di streaming video molto diffuso) e di offrire prestazioni più coerenti a tutti i nostri utenti.
