Cloud Redis latency causes (vs. local redis on macbook pro)
Redis can give sub millisecond response times. That's a great promise. I'm testing heroku redis and I get 1ms up to about 8ms, for a zincrby. I'm using microtime() in php to wrap the call. This heroku redis (I'm using the free plan) is a shared instance and there is resource contention so I expect response times for identical queries to vary, and they certainly do.
I'm curious as to the cause of the difference in performance vs. redis installed on my macbook pro via homebrew. There's obviously no network latency there. What I'm curious about is does this mean that any cloud redis (i.e. connecting over the network, say within aws), is always going to be quite a bit slower than if I were to have one cloud server and run a redis inside the same physical machine, thus eliminating network latency?
There is also resource contention in these cloud offerings, unless a private server is chosen which costs a lot more.
Some numbers: my local macbook pro consistently gives 0.2ms for the identical zincrby that takes between 1ms & 8ms on the heroku redis.
Is network latency the cause of this?
amazon-web-services redis cloud heroku-redis
asked Dec 31 '18 at 12:34
mwalmwal
600416
add a comment |
Redis can give sub millisecond response times. That's a great promise. I'm testing heroku redis and I get 1ms up to about 8ms, for a zincrby. I'm using microtime() in php to wrap the call. This heroku redis (I'm using the free plan) is a shared instance and there is resource contention so I expect response times for identical queries to vary, and they certainly do.
I'm curious as to the cause of the difference in performance vs. redis installed on my macbook pro via homebrew. There's obviously no network latency there. What I'm curious about is does this mean that any cloud redis (i.e. connecting over the network, say within aws), is always going to be quite a bit slower than if I were to have one cloud server and run a redis inside the same physical machine, thus eliminating network latency?
There is also resource contention in these cloud offerings, unless a private server is chosen which costs a lot more.
Some numbers: my local macbook pro consistently gives 0.2ms for the identical zincrby that takes between 1ms & 8ms on the heroku redis.
Is network latency the cause of this?
amazon-web-services redis cloud heroku-redis
asked Dec 31 '18 at 12:34
mwalmwal
600416
For interest, inter-region latency appears always > 10ms: cloudping.co
– mwal
Dec 31 '18 at 12:50
2
I would have expected low latency for redis in the same vpc as the instance. Are you testing on-prem + cloud redis, or cloud-instance + cloud-redis?
– Matthew Arthur
Dec 31 '18 at 13:44
1
@MatthewArthur It's cloud-instance & cloud-redis. But not, of course, as containers running on the same piece of hardware. These are containers running within the same aws region, I think that's all we can know. So it's intra-region latency that's the issue.
– mwal
Jan 2 at 13:22
add a comment |
Redis can give sub millisecond response times. That's a great promise. I'm testing heroku redis and I get 1ms up to about 8ms, for a zincrby. I'm using microtime() in php to wrap the call. This heroku redis (I'm using the free plan) is a shared instance and there is resource contention so I expect response times for identical queries to vary, and they certainly do.
I'm curious as to the cause of the difference in performance vs. redis installed on my macbook pro via homebrew. There's obviously no network latency there. What I'm curious about is does this mean that any cloud redis (i.e. connecting over the network, say within aws), is always going to be quite a bit slower than if I were to have one cloud server and run a redis inside the same physical machine, thus eliminating network latency?
There is also resource contention in these cloud offerings, unless a private server is chosen which costs a lot more.
Some numbers: my local macbook pro consistently gives 0.2ms for the identical zincrby that takes between 1ms & 8ms on the heroku redis.
Is network latency the cause of this?
amazon-web-services redis cloud heroku-redis
asked Dec 31 '18 at 12:34
mwalmwal
600416
Redis can give sub millisecond response times. That's a great promise. I'm testing heroku redis and I get 1ms up to about 8ms, for a zincrby. I'm using microtime() in php to wrap the call. This heroku redis (I'm using the free plan) is a shared instance and there is resource contention so I expect response times for identical queries to vary, and they certainly do.
I'm curious as to the cause of the difference in performance vs. redis installed on my macbook pro via homebrew. There's obviously no network latency there. What I'm curious about is does this mean that any cloud redis (i.e. connecting over the network, say within aws), is always going to be quite a bit slower than if I were to have one cloud server and run a redis inside the same physical machine, thus eliminating network latency?
There is also resource contention in these cloud offerings, unless a private server is chosen which costs a lot more.
Some numbers: my local macbook pro consistently gives 0.2ms for the identical zincrby that takes between 1ms & 8ms on the heroku redis.
Is network latency the cause of this?
amazon-web-services redis cloud heroku-redis
amazon-web-services redis cloud heroku-redis
asked Dec 31 '18 at 12:34
mwalmwal
600416
asked Dec 31 '18 at 12:34
mwalmwal
600416
edited Dec 31 '18 at 18:01
mwal
asked Dec 31 '18 at 12:34
mwalmwal
600416
asked Dec 31 '18 at 12:34
mwalmwal
600416
asked Dec 31 '18 at 12:34
mwalmwal
600416
600416
For interest, inter-region latency appears always > 10ms: cloudping.co
– mwal
Dec 31 '18 at 12:50
2
I would have expected low latency for redis in the same vpc as the instance. Are you testing on-prem + cloud redis, or cloud-instance + cloud-redis?
– Matthew Arthur
Dec 31 '18 at 13:44
1
@MatthewArthur It's cloud-instance & cloud-redis. But not, of course, as containers running on the same piece of hardware. These are containers running within the same aws region, I think that's all we can know. So it's intra-region latency that's the issue.
– mwal
Jan 2 at 13:22
add a comment |
For interest, inter-region latency appears always > 10ms: cloudping.co
– mwal
Dec 31 '18 at 12:50
2
I would have expected low latency for redis in the same vpc as the instance. Are you testing on-prem + cloud redis, or cloud-instance + cloud-redis?
– Matthew Arthur
Dec 31 '18 at 13:44
1
@MatthewArthur It's cloud-instance & cloud-redis. But not, of course, as containers running on the same piece of hardware. These are containers running within the same aws region, I think that's all we can know. So it's intra-region latency that's the issue.
– mwal
Jan 2 at 13:22
For interest, inter-region latency appears always > 10ms: cloudping.co
– mwal
Dec 31 '18 at 12:50
For interest, inter-region latency appears always > 10ms: cloudping.co
– mwal
Dec 31 '18 at 12:50
2
2
I would have expected low latency for redis in the same vpc as the instance. Are you testing on-prem + cloud redis, or cloud-instance + cloud-redis?
– Matthew Arthur
Dec 31 '18 at 13:44
I would have expected low latency for redis in the same vpc as the instance. Are you testing on-prem + cloud redis, or cloud-instance + cloud-redis?
– Matthew Arthur
Dec 31 '18 at 13:44
1
1
@MatthewArthur It's cloud-instance & cloud-redis. But not, of course, as containers running on the same piece of hardware. These are containers running within the same aws region, I think that's all we can know. So it's intra-region latency that's the issue.
– mwal
Jan 2 at 13:22
@MatthewArthur It's cloud-instance & cloud-redis. But not, of course, as containers running on the same piece of hardware. These are containers running within the same aws region, I think that's all we can know. So it's intra-region latency that's the issue.
– mwal
Jan 2 at 13:22
add a comment |
1 Answer
1
active
oldest
votes
No, probably not.
The typical latency of a 1 Gbit/s network is about 200us. That's 0.2ms.
What's more, in aws you're probably on 10gbps at least.
As this page in the redis manual explains, the main cause of the latency variation between these two environments will almost certainly be a result of the higher intrinsic latency (there's a redis command to test this on any particular system: redis-cli --intrinsic-latency 100, see the manual page above) arising from being run in a linux container.
i.e., network latency is not the dominant cause of the variation seen here.
Here is a checklist (from redis manual page linked above).
- If you can afford it, prefer a physical machine over a VM to host the server.
- Do not systematically connect/disconnect to the server (especially true for web based applications). Keep your connections as long lived
as possible.
- If your client is on the same host than the server, use Unix domain sockets.
- Prefer to use aggregated commands (MSET/MGET), or commands with variadic parameters (if possible) over pipelining.
- Prefer to use pipelining (if possible) over sequence of roundtrips.
- Redis supports Lua server-side scripting to cover cases that are not suitable for raw pipelining (for instance when the result of a command
is an input for the following commands).
answered Dec 31 '18 at 17:24
mwalmwal
600416
Something told me aws internal networks were unlikely to be a significant bottleneck... - if they were, they'd be on the case & would have fixed it :)
– mwal
Dec 31 '18 at 17:36
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53987592%2fcloud-redis-latency-causes-vs-local-redis-on-macbook-pro%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
No, probably not.
The typical latency of a 1 Gbit/s network is about 200us. That's 0.2ms.
What's more, in aws you're probably on 10gbps at least.
As this page in the redis manual explains, the main cause of the latency variation between these two environments will almost certainly be a result of the higher intrinsic latency (there's a redis command to test this on any particular system: redis-cli --intrinsic-latency 100, see the manual page above) arising from being run in a linux container.
i.e., network latency is not the dominant cause of the variation seen here.
Here is a checklist (from redis manual page linked above).
- If you can afford it, prefer a physical machine over a VM to host the server.
- Do not systematically connect/disconnect to the server (especially true for web based applications). Keep your connections as long lived
as possible.
- If your client is on the same host than the server, use Unix domain sockets.
- Prefer to use aggregated commands (MSET/MGET), or commands with variadic parameters (if possible) over pipelining.
- Prefer to use pipelining (if possible) over sequence of roundtrips.
- Redis supports Lua server-side scripting to cover cases that are not suitable for raw pipelining (for instance when the result of a command
is an input for the following commands).
answered Dec 31 '18 at 17:24
mwalmwal
600416
Something told me aws internal networks were unlikely to be a significant bottleneck... - if they were, they'd be on the case & would have fixed it :)
– mwal
Dec 31 '18 at 17:36
add a comment |
No, probably not.
The typical latency of a 1 Gbit/s network is about 200us. That's 0.2ms.
What's more, in aws you're probably on 10gbps at least.
As this page in the redis manual explains, the main cause of the latency variation between these two environments will almost certainly be a result of the higher intrinsic latency (there's a redis command to test this on any particular system: redis-cli --intrinsic-latency 100, see the manual page above) arising from being run in a linux container.
i.e., network latency is not the dominant cause of the variation seen here.
Here is a checklist (from redis manual page linked above).
- If you can afford it, prefer a physical machine over a VM to host the server.
- Do not systematically connect/disconnect to the server (especially true for web based applications). Keep your connections as long lived
as possible.
- If your client is on the same host than the server, use Unix domain sockets.
- Prefer to use aggregated commands (MSET/MGET), or commands with variadic parameters (if possible) over pipelining.
- Prefer to use pipelining (if possible) over sequence of roundtrips.
- Redis supports Lua server-side scripting to cover cases that are not suitable for raw pipelining (for instance when the result of a command
is an input for the following commands).
answered Dec 31 '18 at 17:24
mwalmwal
600416
Something told me aws internal networks were unlikely to be a significant bottleneck... - if they were, they'd be on the case & would have fixed it :)
– mwal
Dec 31 '18 at 17:36
add a comment |
No, probably not.
The typical latency of a 1 Gbit/s network is about 200us. That's 0.2ms.
What's more, in aws you're probably on 10gbps at least.
As this page in the redis manual explains, the main cause of the latency variation between these two environments will almost certainly be a result of the higher intrinsic latency (there's a redis command to test this on any particular system: redis-cli --intrinsic-latency 100, see the manual page above) arising from being run in a linux container.
i.e., network latency is not the dominant cause of the variation seen here.
Here is a checklist (from redis manual page linked above).
- If you can afford it, prefer a physical machine over a VM to host the server.
- Do not systematically connect/disconnect to the server (especially true for web based applications). Keep your connections as long lived
as possible.
- If your client is on the same host than the server, use Unix domain sockets.
- Prefer to use aggregated commands (MSET/MGET), or commands with variadic parameters (if possible) over pipelining.
- Prefer to use pipelining (if possible) over sequence of roundtrips.
- Redis supports Lua server-side scripting to cover cases that are not suitable for raw pipelining (for instance when the result of a command
is an input for the following commands).
answered Dec 31 '18 at 17:24
mwalmwal
600416
No, probably not.
The typical latency of a 1 Gbit/s network is about 200us. That's 0.2ms.
What's more, in aws you're probably on 10gbps at least.
As this page in the redis manual explains, the main cause of the latency variation between these two environments will almost certainly be a result of the higher intrinsic latency (there's a redis command to test this on any particular system: redis-cli --intrinsic-latency 100, see the manual page above) arising from being run in a linux container.
i.e., network latency is not the dominant cause of the variation seen here.
Here is a checklist (from redis manual page linked above).
- If you can afford it, prefer a physical machine over a VM to host the server.
- Do not systematically connect/disconnect to the server (especially true for web based applications). Keep your connections as long lived
as possible.
- If your client is on the same host than the server, use Unix domain sockets.
- Prefer to use aggregated commands (MSET/MGET), or commands with variadic parameters (if possible) over pipelining.
- Prefer to use pipelining (if possible) over sequence of roundtrips.
- Redis supports Lua server-side scripting to cover cases that are not suitable for raw pipelining (for instance when the result of a command
is an input for the following commands).
answered Dec 31 '18 at 17:24
mwalmwal
600416
edited Dec 31 '18 at 18:01
answered Dec 31 '18 at 17:24
mwalmwal
600416
answered Dec 31 '18 at 17:24
mwalmwal
600416
answered Dec 31 '18 at 17:24
mwalmwal
600416
600416
Something told me aws internal networks were unlikely to be a significant bottleneck... - if they were, they'd be on the case & would have fixed it :)
– mwal
Dec 31 '18 at 17:36
add a comment |
Something told me aws internal networks were unlikely to be a significant bottleneck... - if they were, they'd be on the case & would have fixed it :)
– mwal
Dec 31 '18 at 17:36
Something told me aws internal networks were unlikely to be a significant bottleneck... - if they were, they'd be on the case & would have fixed it :)
– mwal
Dec 31 '18 at 17:36
Something told me aws internal networks were unlikely to be a significant bottleneck... - if they were, they'd be on the case & would have fixed it :)
– mwal
Dec 31 '18 at 17:36
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53987592%2fcloud-redis-latency-causes-vs-local-redis-on-macbook-pro%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
For interest, inter-region latency appears always > 10ms: cloudping.co
– mwal
Dec 31 '18 at 12:50
2
I would have expected low latency for redis in the same vpc as the instance. Are you testing on-prem + cloud redis, or cloud-instance + cloud-redis?
– Matthew Arthur
Dec 31 '18 at 13:44
1
@MatthewArthur It's cloud-instance & cloud-redis. But not, of course, as containers running on the same piece of hardware. These are containers running within the same aws region, I think that's all we can know. So it's intra-region latency that's the issue.
– mwal
Jan 2 at 13:22