Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have 2 servers, each in two separate locations. I need to host an application on one, and the database server on the other.

From the app server, if I ping the database server, on average I get about 30ms.

My question is:

When I query the database from the app;

Is it going to take 30 ms + database_server_query_run_time


Is it going to take 30 ms + database_server_query_run_time + 30ms

I would like to understand this please.

share|improve this question
add comment

2 Answers 2

up vote 6 down vote accepted

It will usually take more then those two options.

Ping measures just the time from client, to server, and back again (rtt - round trip time)

Usually databases use TCP, so you first need to send a SYN packet to start the TCP handshake (to simplify let's say 15ms* + cpu time, then you recieve and SYN/ACK (15ms+cpu time), send back an ACK and a request (atleast 15ms + cpu time), then the time for the DB to process the query, and then the time (15ms + cpu) to get the data back, and a bit more to ack, and close the connection.

This is ofcourse not counting the authentication (username/password) to the database, and no encryption (ssl handshakes/DH or whatever is needed).

*half of a round trip time, assuming the route there and back is symmetrical (half the time to get there, and half to get back... cpu processing time for ping reply is very short)

share|improve this answer
The problem of three-way-handshake could be encountered with persistent TCP sessions. –  Michuelnik Oct 15 '12 at 12:57
@Michuelnik, could you please elaborate? I would really like to understand this whole thing and find the best way to minimize the latency for querying the DB. –  Phil Oct 15 '12 at 12:58
Sadly, most software (atleast web apps) dont's support this :/ But the idea is, to establish the connection (once) to the DB, and keep the connection running (open), and just keep sending queries/getting replys over one, constantly open connection. This eliminates the need for tcp handshakes, authentication, etc. each time. –  mulaz Oct 15 '12 at 13:01
mulaz, thank you for explaining. I'll be working with Python so we shall see how it goes. ;-) –  Phil Oct 15 '12 at 13:42
Don't forget the size of the request and the reply. For example, over a 1MB/sec link, a 100KB payload would take an extra 100ms to transport. –  Dustin Boswell Jun 26 at 3:01
add comment

The ping time is round trip. If you think about it -- how could it measure the one way time? So it will take 30ms plus the query time.

share|improve this answer
I'll just add that is probably going to take a bit longer than just the 30 secs +query time. since Ping is ICMP and your DB connection is TCP, you will also have setup/handshake, and DB Connection initiation etc in there as well –  Doon Oct 15 '12 at 12:51
@Doon: Which could be "avoided" with persistent TCP/database connections –  Michuelnik Oct 15 '12 at 12:57
@Michuelnik, do you think that persistent DB connection is the way to go here? Will it cause some other issues? –  Phil Oct 15 '12 at 12:59
@michuelnik , of course. Was just pointing out it isn't as simple as RTT + Query. There are also Limits to Max Speed, per session due to latency, etc..) –  Doon Oct 15 '12 at 12:59
@phil In most cases it Persistent DB connections are beneficial, if you are going to do be doing multiple queries. If queries are spread out /sporadic you are tying up resources unnecessarily, but if queries are coming all the time, etc. you will save a non trivial amount of overhead by reusing the existing connection as opposed to opening a new one on each request. –  Doon Oct 15 '12 at 13:01
show 1 more comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.