Domanda

Attualmente sto lavorando a un sistema di livello n e sto affrontando alcuni problemi di prestazioni del database. Un'area su cui abbiamo studiato è la latenza tra il server di database e il server delle applicazioni. Nel nostro ambiente di test il i tempi medi di ping tra le due caselle sono nella regione di 0,2 ms, tuttavia sul sito dei client è più nella regione di 8,2 ms. È questo qualcosa di cui dovremmo preoccuparci?

Per il tuo sistema medio, cosa consideri una latenza accettabile e come faresti per testare / misurare la latenza?

Karl

È stato utile?

Soluzione

In breve: no!

Quello che dovresti monitorare sono le prestazioni globali delle tue query (es. trasporto al DB + esecuzione + trasporto al tuo server)

Quello che potresti fare è usare un contatore delle prestazioni per monitorare il tempo che le tue query richiedono normalmente per essere eseguite. Probabilmente vedrai che i tuoi risultati si trovano nell'area dei millisecondi.

Non esiste una cosa come "ragionevole latenza". Dovresti piuttosto considerare la "ragionevole latenza per il tuo progetto", che varierebbe molto a seconda di cosa stai lavorando. Le persone non hanno le stesse aspettative per una piattaforma di trading in tempo reale e per un sito Web amatoriale di sola lettura.

Altri suggerimenti

Ci scusiamo per la risposta molto prematura, ma mi sono imbattuto in questa domanda quando stavo cercando le metriche di quali latenze di rete altri stavano raggiungendo tra il loro app server e il server db. Comunque, ho notato che le altre risposte

Comunque, in breve: sì, la latenza di rete (misurata dal ping) può fare una grande differenza.

Se la risposta del tuo database è .001ms, vedrai un enorme impatto passando da un ping da 0,2ms a 8ms. Ho sentito che i protocolli di database sono chiacchieroni, il che, se vero, significa che sarebbero influenzati maggiormente dalla latenza della rete lenta rispetto a http.

E molto probabilmente, se stai eseguendo 1 query, l'aggiunta di 8 ms per ottenere la risposta dal db non avrà importanza. Ma se stai facendo 10.000 query che si verificano generalmente con un codice errato o un uso non ottimizzato di un ORM, dovrai attendere altri 80 secondi per un ping di 8 ms, mentre per un ping di 0,2 ms, aspetteresti solo 4 secondi.

Per quanto mi riguarda, non ho mai permesso alle applicazioni client di contattare direttamente il database. Richiedo che le applicazioni client passino sempre attraverso un server delle applicazioni (ad esempio un servizio Web REST). In questo modo, se per sbaglio ho un " 1 + N " Problema ORM, quindi non è altrettanto efficace. Proverei comunque a risolvere il problema di fondo ...

Su un server basato su Linux puoi testare tu stesso l'effetto della latenza usando il comando tc.

Ad esempio questo comando aggiungerà 10ms di ritardo a tutti i pacchetti che passano attraverso eth0

tc qdisc add dev eth0 root netem delay 10ms

usa questo comando per rimuovere il ritardo

tc qdisc del dev eth0 root

Maggiori dettagli disponibili qui: http://devresources.linux-foundation.org/shemminger/netem/example. html

Tutte le applicazioni differiranno, ma ho sicuramente visto situazioni in cui una latenza di 10 ms ha avuto un impatto significativo sulle prestazioni del sistema.

Uno dei principali honchos di reply.com ha dichiarato, secondo i loro studi, che il tempo di attesa di 400 ms per il caricamento di una pagina Web è circa il momento in cui iniziano a convincere le persone ad annullare il caricamento della pagina e ad andare altrove. Il mio consiglio è di esaminare l'intero processo, dalla richiesta del cliente originale alla realizzazione e se stai andando bene lì, non c'è bisogno di ottimizzare ulteriormente. 8,2 ms vs 0,2 ms è esponenzialmente più grande in senso matematico, ma da un punto di vista umano nessuno può davvero percepire una differenza di 8,0 ms. È per questo che hanno le rifiniture fotografiche nelle gare;)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top