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

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

Ci vorranno 30 ms + database_server_query_run_time+ 30ms

Vorrei capire questo per favore.

networking ping latency

— Phil
fonte

Risposte:

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)

— Mulaz
fonte

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

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,

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.

— David Schwartz
fonte

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,