我们正在运行一个Web应用程序，并从memcached切换到redis（2.4）进行缓存。现在我们对redis性能有些失望。 Redis在同一台服务器上运行，我们只使用非常简单的GET和SET操作。在一些大量使用缓存值的请求中，我们对redis有多达300个GET请求，但这些请求最多需要150毫秒。我们有大约200,000个活动密钥，每秒大约有1,000个redis请求。磁盘io，ram或cpu没有问题。由于我们现有的代码，我们不能简单地将redis请求组合在一起。 Memcached的速度提高了约4倍。 我们对redis的看法是，我们不需要任何缓存升温，并且可以在将来使用更高级的数据存储功能。我们期望redis执行类似于memcached。所以也许我们在配置中遗漏了一些东西，这基本上是默认配置。
你知道redis性能调优的最佳实践吗？
答案 0 :(得分：22)
首先，您可能需要阅读the Redis benchmark page。它提供了检查调整Redis的要点的一个很好的总结。
即使您不使用流水线操作，150毫秒内300 GET也不是那么高效。这意味着平均延迟为500 us。但是，它实际上取决于对象的大小。更大的对象，更多的延迟。在我非常老的2 GHz AMD盒子上，我可以测量150个小物体的延迟（几个字节）。
要快速检查Redis实例的平均延迟，您可以使用：
$ redis-cli --latency
请务必使用最新的Redis版本（不是2.4版）来获取此选项。 注意：2.4现在很老了，使用Redis 2.6 - 如果需要，编译你自己的Redis版本，它真的很简单。
要快速运行基准来研究延迟，您可以启动：
$ redis-benchmark -q -n 10000 -c 1 -d average_size_of_your_objects_in_bytes
它使用唯一连接运行，没有流水线操作，因此可以从吞吐量中推断出延迟。尝试将这些基准测试的结果与您的应用程序测量的数据进行比较。
您可能需要检查以下几点：
为什么memcached会更好？好吧，单个memcached实例肯定更具可伸缩性，并且可能比单个Redis实例更具响应性，因为它可能在多个线程上运行。 Redis很快，但是单线程 - 所有命令的执行都是序列化的。因此，当一个命令正在进行连接时，所有其他客户端都必须等待 - 给定命令的延迟时间也会影响所有挂起的命令。通常，在低吞吐量的情况下，性能可比较。
以1000 q / s（Redis或memcached标准的低吞吐量），我会说你的问题更可能发生在客户端（即选择客户端库，连接/断开连接......等等） ，而不是Redis服务器本身。
最后我要提一下，如果你为每个HTTP请求生成一些Redis查询，请考虑pipelining尽可能发送给Redis的命令。这是开发高效Redis应用程序的关键点。
如果您的应用程序服务器与Redis位于同一个框中，您还可以使用unix域套接字而不是TCP环回来连接到Redis。它略微提高了性能（不使用流水线时，吞吐量增加了50％）。
答案 1 :(得分：0)
检查redis是否正在使用OS交换内存。如果是那样会增加延迟。 要找到答案，请在此处搜索“交换引起的延迟”：http://redis.io/topics/latency
如果您的服务器硬件支持NUMA，最好使用numactl启动redis-server。 如果您从使用NUMA的redis-server开始，请不要忘记在sysctl中关闭区域回收模式（vm.zone_reclaim_mode = 0）。
答案 2 :(得分：0)
尝试在Lua脚本中编写300 GET请求的脚本。它应该工作得更快，因为即使您的客户端代码在本地运行到Redis，您也可以节省触摸TCP / IP堆栈的时间。