Dati ottenuti dal ping: è andata e ritorno o solo andata?


28

Ho 2 server, ognuno in due posizioni separate. Devo ospitare un'applicazione su uno e il server di database sull'altro.

Dal server app, se eseguo il ping del server database, in media ottengo circa 30ms.

La mia domanda è:

When I query the database from the app;

Ci vorrà 30 ms + database_server_query_run_time

O;

Ci vorranno 30 ms + database_server_query_run_time+ 30ms

Vorrei capire questo per favore.

Risposte:


24

Di solito ci vorranno più di quelle due opzioni.

Il ping misura il tempo dal client al server e viceversa (rtt - round trip time)

Di solito i database usano TCP, quindi devi prima inviare un pacchetto SYN per avviare l'handshake TCP (per semplificare diciamo 15ms * + cpu time, quindi ricevi e SYN / ACK (15ms + cpu time), rispedisci un ACK e un richiesta (almeno 15ms + cpu time), quindi il tempo per l'elaborazione della query da parte del DB, quindi il tempo (15ms + cpu) per recuperare i dati, e ancora un po 'per riagganciare e chiudere la connessione.

Ovviamente questo non conta l'autenticazione (nome utente / password) nel database e nessuna crittografia (ssl handshakes / DH o qualunque cosa sia necessaria).

* metà del tempo di andata e ritorno, supponendo che il percorso andata e ritorno sia simmetrico (metà del tempo per arrivarci e metà per tornare ... il tempo di elaborazione della CPU per la risposta al ping è molto breve)


Il problema dell'handshake a tre vie potrebbe essere riscontrato con sessioni TCP persistenti.
Michuelnik,

@Michuelnik, potresti per favore elaborare? Mi piacerebbe davvero capire tutto questo e trovare il modo migliore per ridurre al minimo la latenza per l'interrogazione del DB.
Phil

2
Purtroppo, la maggior parte dei software (almeno web app) non supporta questo: / Ma l'idea è, stabilire la connessione (una volta) al DB e mantenere la connessione in esecuzione (aperta) e continuare a inviare query / ottenere risposte su una, connessione costantemente aperta. Ciò elimina ogni volta la necessità di handshake, autenticazione, ecc.
mulaz,

Mulaz, grazie per aver spiegato. Lavorerò con Python, quindi vedremo come va. ;-)
Phil

Non dimenticare le dimensioni della richiesta e della risposta. Ad esempio, su un collegamento da 1 MB / sec, un carico utile di 100 KB richiederebbe 100ms in più per il trasporto.
Dustin Boswell,

7

Il tempo di ping è di andata e ritorno. Se ci pensate, come potrebbe misurare il tempo a senso unico? Quindi ci vorranno 30ms più il tempo di query.


1
Aggiungerò semplicemente che probabilmente ci vorrà un po 'più di tempo rispetto ai soli 30 secondi + tempo di query. dato che Ping è ICMP e la tua connessione DB è TCP, avrai anche setup / handshake e avvio connessione DB ecc.
Doon,

@Doon: che potrebbe essere "evitato" con connessioni TCP / database persistenti
Michuelnik,

@Michuelnik, pensi che la connessione DB persistente sia la strada da percorrere qui? Causerà altri problemi?
Phil

@michuelnik, ovviamente. Stavo solo sottolineando che non è semplice come RTT + Query. Ci sono anche limiti alla velocità massima, per sessione a causa della latenza, ecc.)
Doon,

@phil Nella maggior parte dei casi le connessioni a DB persistenti sono utili, se hai intenzione di fare più query. Se le query vengono distribuite / sporadiche, si stanno raccogliendo risorse inutilmente, ma se le query arrivano continuamente, ecc., Si risparmierà una quantità non banale di sovraccarico riutilizzando la connessione esistente anziché aprirne una nuova su ogni richiesta.
Doon,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.