Why are initial connections always slower
up vote
2
down vote
favorite
I first noticed this when using Insomnia (HTTP clients) to test some of my API endpoints.
The first request I make to my API server (and others) is always 100ms+ but sequential requests are always super quick latency wise.
How is this possible? I tried sending random data each request and this is still happening. I also recently heard of QUIC protocol by Google which is meant to reduce handshake request round trips from ~3 to 0 for common servers. This makes a lot of sense to what is happening but QUIC is not even deployed web-wide yet.
http tcp web udp
New contributor
|
show 2 more comments
up vote
2
down vote
favorite
I first noticed this when using Insomnia (HTTP clients) to test some of my API endpoints.
The first request I make to my API server (and others) is always 100ms+ but sequential requests are always super quick latency wise.
How is this possible? I tried sending random data each request and this is still happening. I also recently heard of QUIC protocol by Google which is meant to reduce handshake request round trips from ~3 to 0 for common servers. This makes a lot of sense to what is happening but QUIC is not even deployed web-wide yet.
http tcp web udp
New contributor
2
Is DNS involved?
– Kamil Maciorowski
22 hours ago
Haha. That's it then. But why does DNS take 100ms+??
– Kirk122
22 hours ago
2
It really depends on your setup. But one possible explanation (taking DNS into account) would be that your client doesn't have a cached entry for that server. So before being able to make a request it would need to do a DNS lookup in order to know which server to connect to. The server and your client may also support keep alive so maybe the connection isn't closed between requests.
– Seth
21 hours ago
QUIC can reduce latencies, but not to zero. It works by creating it's own mechanism which behaves somewhat similar to tcp by using udp, and overcoming some of the limits in the tcp protocol. It's not magic though.
– davidgo
20 hours ago
It might also be session management on the remote endpoint. The first time you connect it’s allocating resources to the connection and starting up threads. After that you’re just reusing the same resources until they timeout and are freed.
– Appleoddity
16 hours ago
|
show 2 more comments
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I first noticed this when using Insomnia (HTTP clients) to test some of my API endpoints.
The first request I make to my API server (and others) is always 100ms+ but sequential requests are always super quick latency wise.
How is this possible? I tried sending random data each request and this is still happening. I also recently heard of QUIC protocol by Google which is meant to reduce handshake request round trips from ~3 to 0 for common servers. This makes a lot of sense to what is happening but QUIC is not even deployed web-wide yet.
http tcp web udp
New contributor
I first noticed this when using Insomnia (HTTP clients) to test some of my API endpoints.
The first request I make to my API server (and others) is always 100ms+ but sequential requests are always super quick latency wise.
How is this possible? I tried sending random data each request and this is still happening. I also recently heard of QUIC protocol by Google which is meant to reduce handshake request round trips from ~3 to 0 for common servers. This makes a lot of sense to what is happening but QUIC is not even deployed web-wide yet.
http tcp web udp
http tcp web udp
New contributor
New contributor
edited 21 hours ago
Tomasz Jakub Rup
510313
510313
New contributor
asked 22 hours ago
Kirk122
133
133
New contributor
New contributor
2
Is DNS involved?
– Kamil Maciorowski
22 hours ago
Haha. That's it then. But why does DNS take 100ms+??
– Kirk122
22 hours ago
2
It really depends on your setup. But one possible explanation (taking DNS into account) would be that your client doesn't have a cached entry for that server. So before being able to make a request it would need to do a DNS lookup in order to know which server to connect to. The server and your client may also support keep alive so maybe the connection isn't closed between requests.
– Seth
21 hours ago
QUIC can reduce latencies, but not to zero. It works by creating it's own mechanism which behaves somewhat similar to tcp by using udp, and overcoming some of the limits in the tcp protocol. It's not magic though.
– davidgo
20 hours ago
It might also be session management on the remote endpoint. The first time you connect it’s allocating resources to the connection and starting up threads. After that you’re just reusing the same resources until they timeout and are freed.
– Appleoddity
16 hours ago
|
show 2 more comments
2
Is DNS involved?
– Kamil Maciorowski
22 hours ago
Haha. That's it then. But why does DNS take 100ms+??
– Kirk122
22 hours ago
2
It really depends on your setup. But one possible explanation (taking DNS into account) would be that your client doesn't have a cached entry for that server. So before being able to make a request it would need to do a DNS lookup in order to know which server to connect to. The server and your client may also support keep alive so maybe the connection isn't closed between requests.
– Seth
21 hours ago
QUIC can reduce latencies, but not to zero. It works by creating it's own mechanism which behaves somewhat similar to tcp by using udp, and overcoming some of the limits in the tcp protocol. It's not magic though.
– davidgo
20 hours ago
It might also be session management on the remote endpoint. The first time you connect it’s allocating resources to the connection and starting up threads. After that you’re just reusing the same resources until they timeout and are freed.
– Appleoddity
16 hours ago
2
2
Is DNS involved?
– Kamil Maciorowski
22 hours ago
Is DNS involved?
– Kamil Maciorowski
22 hours ago
Haha. That's it then. But why does DNS take 100ms+??
– Kirk122
22 hours ago
Haha. That's it then. But why does DNS take 100ms+??
– Kirk122
22 hours ago
2
2
It really depends on your setup. But one possible explanation (taking DNS into account) would be that your client doesn't have a cached entry for that server. So before being able to make a request it would need to do a DNS lookup in order to know which server to connect to. The server and your client may also support keep alive so maybe the connection isn't closed between requests.
– Seth
21 hours ago
It really depends on your setup. But one possible explanation (taking DNS into account) would be that your client doesn't have a cached entry for that server. So before being able to make a request it would need to do a DNS lookup in order to know which server to connect to. The server and your client may also support keep alive so maybe the connection isn't closed between requests.
– Seth
21 hours ago
QUIC can reduce latencies, but not to zero. It works by creating it's own mechanism which behaves somewhat similar to tcp by using udp, and overcoming some of the limits in the tcp protocol. It's not magic though.
– davidgo
20 hours ago
QUIC can reduce latencies, but not to zero. It works by creating it's own mechanism which behaves somewhat similar to tcp by using udp, and overcoming some of the limits in the tcp protocol. It's not magic though.
– davidgo
20 hours ago
It might also be session management on the remote endpoint. The first time you connect it’s allocating resources to the connection and starting up threads. After that you’re just reusing the same resources until they timeout and are freed.
– Appleoddity
16 hours ago
It might also be session management on the remote endpoint. The first time you connect it’s allocating resources to the connection and starting up threads. After that you’re just reusing the same resources until they timeout and are freed.
– Appleoddity
16 hours ago
|
show 2 more comments
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
As other mentioned in the comments to your initial post that it could be DNS, which is a very reasonable idea as to the cause of the delay.
However, there is no way for us to know the actual answer to your question. We dont know what is going on with your setup, nor can we, without access.
There is a tool you can use to diagnose the problem. Fiddler is an excellent tool, in which I can highly recommend. It can help diagnose web based problems. I suggest you give it a shot.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
As other mentioned in the comments to your initial post that it could be DNS, which is a very reasonable idea as to the cause of the delay.
However, there is no way for us to know the actual answer to your question. We dont know what is going on with your setup, nor can we, without access.
There is a tool you can use to diagnose the problem. Fiddler is an excellent tool, in which I can highly recommend. It can help diagnose web based problems. I suggest you give it a shot.
add a comment |
up vote
0
down vote
accepted
As other mentioned in the comments to your initial post that it could be DNS, which is a very reasonable idea as to the cause of the delay.
However, there is no way for us to know the actual answer to your question. We dont know what is going on with your setup, nor can we, without access.
There is a tool you can use to diagnose the problem. Fiddler is an excellent tool, in which I can highly recommend. It can help diagnose web based problems. I suggest you give it a shot.
add a comment |
up vote
0
down vote
accepted
up vote
0
down vote
accepted
As other mentioned in the comments to your initial post that it could be DNS, which is a very reasonable idea as to the cause of the delay.
However, there is no way for us to know the actual answer to your question. We dont know what is going on with your setup, nor can we, without access.
There is a tool you can use to diagnose the problem. Fiddler is an excellent tool, in which I can highly recommend. It can help diagnose web based problems. I suggest you give it a shot.
As other mentioned in the comments to your initial post that it could be DNS, which is a very reasonable idea as to the cause of the delay.
However, there is no way for us to know the actual answer to your question. We dont know what is going on with your setup, nor can we, without access.
There is a tool you can use to diagnose the problem. Fiddler is an excellent tool, in which I can highly recommend. It can help diagnose web based problems. I suggest you give it a shot.
answered 21 hours ago
Keltari
48.6k17112160
48.6k17112160
add a comment |
add a comment |
Kirk122 is a new contributor. Be nice, and check out our Code of Conduct.
Kirk122 is a new contributor. Be nice, and check out our Code of Conduct.
Kirk122 is a new contributor. Be nice, and check out our Code of Conduct.
Kirk122 is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1374943%2fwhy-are-initial-connections-always-slower%23new-answer', 'question_page');
}
);
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
Is DNS involved?
– Kamil Maciorowski
22 hours ago
Haha. That's it then. But why does DNS take 100ms+??
– Kirk122
22 hours ago
2
It really depends on your setup. But one possible explanation (taking DNS into account) would be that your client doesn't have a cached entry for that server. So before being able to make a request it would need to do a DNS lookup in order to know which server to connect to. The server and your client may also support keep alive so maybe the connection isn't closed between requests.
– Seth
21 hours ago
QUIC can reduce latencies, but not to zero. It works by creating it's own mechanism which behaves somewhat similar to tcp by using udp, and overcoming some of the limits in the tcp protocol. It's not magic though.
– davidgo
20 hours ago
It might also be session management on the remote endpoint. The first time you connect it’s allocating resources to the connection and starting up threads. After that you’re just reusing the same resources until they timeout and are freed.
– Appleoddity
16 hours ago