为什么Redis SET的性能要比GET好? [英] Why is Redis SET performance better than GET?

查看:191
本文介绍了为什么Redis SET的性能要比GET好?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

根据Redis 基准 s,Redis可以执行100'000 SET/s和80'000 GET操作/秒.Redis是内存中的数据库,这似乎令人惊讶,因为通常人们会期望内存写入比读取慢一些,例如考虑到SET需要先分配内存才能写入值.

According to the Redis benchmarks , Redis can perform 100'000 SET operations/s, and 80'000 GET operations/s. Redis being an in-memory DB, this seems surprising because typically one would expect that memory writes are somewhat slower than reads, e.g. considering that SETs need to allocate memory prior to being able to write a value.

有人可以解释为什么SET比GET快吗?

Can someone explain why SET is faster than GET?

推荐答案

实际上,这仅是一种效果,默认情况下,您测量的I/O比实际命令执行时间更多.如果您开始在基准测试中启用流水线操作,则它实际上是对实际命令性能的衡量标准,数字将发生变化:

Actually this is only an effect that by default you measure more I/O than the actual command execution time. If you start enabling pipelining in the benchmark, it is a bit more the measure of the actual command performance, and the numbers will change:

$ redis-benchmark -q -n 1000000 -P 32 set foo bar
set foo bar: 338964.03
$ redis-benchmark -q -n 1000000 -P 32 get foo
get foo: 432713.09 requests per second

现在GET更快了:-)

Now GET is faster :-)

我们应该在基准测试文档页面中添加流水线.

We should include pipelining in our benchmark doc page.

编辑:这在这里更加明显:

This is even more evident here:

redis 127.0.0.1:6379> info commandstats
# Commandstats
cmdstat_get:calls=1001568,usec=221845,usec_per_call=0.22
cmdstat_set:calls=831104,usec=498235,usec_per_call=0.60

此命令提供CPU时间以内部为请求提供服务,而无需考虑I/O.SET的处理速度慢了三倍.

This command provides CPU time to serve the request internally, without accounting for I/O. SET is three times slower to process.

这篇关于为什么Redis SET的性能要比GET好?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆