已关闭，此问题需要更focused。它目前不接受回答。
**想改善这个问题吗？**更新问题，使其只关注editing this post的一个问题。
关闭27天前。
社区在27天前审查了是否重新打开这个问题，并将其关闭：
原始关闭原因未解决
Improve this question
我们正在运行一个web应用程序，并从memcached切换到redis（2.4）进行缓存。现在我们对redis的表现有些失望。Redis运行在同一台服务器上，我们只使用非常简单的GET和SET操作。在一些大量使用缓存值的请求中，我们有多达300个GET请求到redis，但这些请求需要150毫秒。我们有大约200，000个活动密钥，每秒大约有1，000个Redis请求。磁盘io，ram或cpu没有问题。由于我们现有的代码，我们不能简单地将redis请求分组在一起。Memcached的速度快了大约4倍。我们喜欢redis的地方是，我们不需要任何缓存预热，而且将来可以使用更高级的缓存功能。我们期望redis的性能与memcached类似。因此，也许我们在配置中遗漏了一些东西，这基本上是默认配置。
你知道redis性能调优的最佳实践吗？
3条答案
按热度按时间0s7z1bwu1#
首先，你可能想读the Redis benchmark page。它提供了一个很好的要点总结，以检查调优Redis。
即使假设你不使用流水线，150 ms内300 Gbit也不是那么有效。这意味着平均延迟是500 us。但是，这实际上取决于对象的大小。对象越大，延迟越长。在我非常旧的2 GHz AMD盒子上，我可以为小对象（几个字节）测量150 us的延迟。
要快速查看Redis示例的平均延迟，您可以使用：用途：
请确保使用最新的Redis版本（而不是2.4）来获取此选项。注意：Redis 2.4现在已经很老了，使用Redis 2.6 -如果需要的话编译你自己的Redis版本，它真的很简单。
要快速运行基准测试以研究延迟，您可以启动：
它使用唯一的连接运行，没有流水线，因此延迟可以从吞吐量中推断出来。尝试将这些基准测试的结果与您的应用程序测量的数据进行比较。
您可能需要检查以下几点：
为什么memcached更好？当然，一个memcached示例比一个Redis示例更具可伸缩性，并且可能响应更快，因为它可以在多个线程上运行。Redis速度很快，但它是单线程的--所有命令的执行都是串行的。因此，当一个命令正在进行连接时，所有其他客户端都必须等待-给定命令的延迟也会影响所有挂起的命令。通常，在低吞吐量下，性能是相当的。
在1000 q/s（Redis或memcached标准的低吞吐量）时，我会说你的问题更有可能是在客户端（即，客户端库的选择，连接/断开等），而不是Redis服务器本身。
最后，我应该提到，如果你在每个HTTP请求中生成了大量的Redis查询，那么尽可能考虑将pipelining作为你发送给Redis的命令。这是开发高效Redis应用的关键。
如果你的应用服务器和Redis在同一个盒子上，你也可以使用unix域套接字而不是TCP端口连接到Redis。它稍微提高了性能（当不使用流水线时，吞吐量增加了50%）。
xzv2uavs2#
检查redis是否使用OS交换内存。如果是，那么这将增加延迟。要找到答案，请在此处搜索“由交换引起的延迟”：http://redis.io/topics/latency
如果您的服务器硬件支持NUMA，最好使用numactl启动redis-server。如果您使用NUMA启动redis-server，请不要忘记在sysctl中关闭区域回收模式（vm.zone_reclaim_mode=0）。
ttisahbt3#
尝试在Lua脚本中编写300 GET请求。它应该工作得更快，因为即使你的客户端代码在Redis本地运行，你也可以节省保存与TCP/IP栈接触的时间。