Ho erroneamente supposto che il mio test AB interno significa che il mio server è in grado di gestire 1k di concorrenza @ 3k hit al secondo.

La mia teoria al momento è che la rete è il collo di bottiglia. Il server non può inviare abbastanza dati abbastanza velocemente.

I test esterni di blitz.io con 1k di concorrenza mostrano che i miei successi si chiudono a 180, con pagine che impiegano sempre più tempo a rispondere poiché il server è in grado di restituire solo 180 al secondo.

Ho servito un file vuoto da nginx e lo ho messo in panchina: scala 1: 1 con concorrenza.

Ora per escludere i colli di bottiglia di IO / memcached (normalmente nginx estrae da memcached), offro una versione statica della pagina cache dal filesystem.

I risultati sono molto simili al mio test originale; Sono limitato a circa 180 RPS.

Dividere la pagina HTML a metà mi dà il doppio dell'RPS, quindi è decisamente limitato dalle dimensioni della pagina.

Se apache internamente ApacheBench dal server locale, ottengo risultati coerenti di circa 4k RPS sia sulla pagina intera che sulla mezza pagina, a velocità di trasferimento elevate. Velocità di trasferimento: 62586,14 [Kbyte / sec] ricevuti

Se eseguo AB da un server esterno, ottengo circa 180 RPS, come i risultati di blitz.io.

Come faccio a sapere che non è un throttling intenzionale?

Se eseguo il benchmark da più server esterni, tutti i risultati diventano scarsi, il che mi porta a credere che il problema sia nel traffico in uscita dei MIEI server, non un problema di velocità di download con i miei server di benchmark / blitz.io.

Quindi sono tornato alla mia conclusione che il mio server non è in grado di inviare dati abbastanza velocemente.

Ho ragione? Esistono altri modi per interpretare questi dati? È la soluzione / ottimizzazione per impostare più server + bilanciamento del carico che può servire a 180 accessi al secondo?

Sono abbastanza nuovo per l'ottimizzazione del server, quindi apprezzerei qualsiasi conferma interpretando questi dati.

Traffico in uscita

Ecco ulteriori informazioni sulla larghezza di banda in uscita: il grafico di rete mostra un output massimo di 16 Mb / s: 16 megabit al secondo. Non suona molto.

A causa di un suggerimento sulla limitazione, ho esaminato questo e ho scoperto che linode ha un limite di 50 Mbps (che a quanto pare non sono nemmeno vicino a colpire). L'ho fatto alzare a 100 Mbps.

Dato che linode limita il mio traffico e non lo sto nemmeno colpendo, questo significa che il mio server dovrebbe davvero essere in grado di produrre fino a 100 Mbps ma è limitato da qualche altro collo di bottiglia interno? Semplicemente non capisco come funzionano le reti su così larga scala; possono letteralmente inviare dati più velocemente che possono leggere dall'HDD? La pipe di rete è così grande?

In conclusione

1: Sulla base di quanto sopra, sto pensando di poter sicuramente aumentare il mio 180RPS aggiungendo un bilanciamento del carico nginx sopra una configurazione del server multi nginx esattamente a 180RPS per server dietro l'LB.

2: Se linode ha un limite di 50 / 100mbit che non sto colpendo affatto, ci deve essere qualcosa che posso fare per raggiungere quel limite con la mia configurazione a server singolo. Se riesco a leggere / trasmettere dati abbastanza velocemente localmente e linode disturba anche avere un limite di 50mbit / 100mbit, ci deve essere un collo di bottiglia interno che non mi consente di colpire quei tappi che non sono sicuro di come rilevare. Corretta?

Mi rendo conto che la domanda è enorme e vaga ora, ma non sono sicuro di come condensarla. Ogni input è apprezzato per qualsiasi conclusione che ho fatto.

Il problema era che supponevo che i picchi del grafico linode.com fossero picchi reali. Si scopre che il grafico utilizza punti dati medi di 5 minuti, quindi il mio picco sembrava essere di 24 MB quando in effetti stavo colpendo il limite di 50 mbit.

Ora che l'hanno aumentato a 100 MB, i miei parametri di riferimento sono immediatamente saliti al nuovo limite di traffico in uscita.

Se solo l'avessi notato prima! Gran parte del mio ragionamento dipendeva dall'idea che non stavo raggiungendo un limite di traffico in uscita a causa di quel grafico.

Ora, raggiungo il picco di 370 richieste al secondo, che è proprio sotto i 100 Mbps, a quel punto inizio a ricevere un "backlog" di richieste e i tempi di risposta iniziano a salire.

Ora posso aumentare la massima concorrenza riducendo la pagina; con gzip abilitato ottengo 600RPS.

Riscontro ancora problemi quando improvvisamente raggiungo il picco e l'arretrato di richieste in sospeso (limitate dalla larghezza di banda) inizia ad accumularsi, ma sembra una domanda diversa.

È stata un'ottima lezione di ottimizzazione / lettura di questi dati / restringimento dei possibili problemi. Grazie mille per il tuo contributo!

Un po 'tardi ora che l'hai capito ... ma forse dovresti considerare di leggere il blog ServerFault di volta in volta.

Sto pensando in particolare a questo post , in cui discutono del perché avere un intervallo di polling di un secondo non lo tagli di tanto in tanto, in relazione a un problema molto simile a quello che hai avuto ..

Abbiamo scoperto che stavamo scartando i pacchetti abbastanza frequentemente su interfacce da 1 Gbit / s a ​​velocità di soli 10-30 MBit / s che danneggiano le nostre prestazioni. Questo perché quella velocità di 10-30 MBit / s è in realtà il numero di bit trasferiti per 5 minuti convertiti in una frequenza di un secondo. Quando ci siamo avvicinati a Wireshark e abbiamo usato la grafica IO di un millisecondo, abbiamo visto che avremmo spesso fatto scoppiare la frequenza di 1 Mbit per millisecondo delle interfacce cosiddette 1 Gbit / s.

Sicuramente mi ha fatto pensare. E so solo che lo sto sballando sugli altri SA nel mio negozio la prima possibilità che ottengo, e sembrerò maliziosamente brillante e percettivo quando affronteremo questo problema.

Chissà, potrei anche lasciarne alcuni nel segreto. :)

Potrebbe essere limitato dalla rete, ma non necessariamente semplicemente una questione di larghezza di banda. La latenza dell'unità di test remota avrà un effetto sul numero di connessioni in sospeso in un determinato momento (attendere 50 ms per i riconoscimenti è molto diverso da 0,5 ms localmente) nonché sulla negoziazione e la stabilizzazione delle dimensioni delle finestre man mano che la connessione avanza. Probabilmente sei anche esposto a una certa quantità di perdita di pacchetti - in funzione della congestione o come meccanismo di limitazione della larghezza di banda da parte del tuo gestore (o di quelli a monte).

Suggerirei di eliminare il più possibile dall'equazione per disegnare una linea di base sensata. Misura il picco di larghezza di banda, latenza e perdita di pacchetti dal tuo server a pochi punti su Internet in generale. Per quanto improbabile possa sembrare, prova a cercare "Test traffico Voip" o simile. Numerosi fornitori di servizi VOIP dispongono di app in grado di misurare questo tipo di modelli (bidirezionalmente) con un discreto grado di precisione. Una volta che hai alcuni dati empirici validi sulla velocità utile effettiva del tuo link, i tuoi risultati potrebbero essere validati.

Oltre ai test della larghezza di banda, potrebbe anche essere utile esaminare un'acquisizione di pacchetti del traffico Web secondario per cercare un numero eccessivo di ritrasmissioni e misurare il tempo apparente che il server impiega a rispondere alle richieste (..se questo il valore sta aumentando sostanzialmente in funzione del numero di connessioni, questo è un grande indizio).