首先，您可能希望阅读Redis基准测试页面。它提供了一个很好的摘要，介绍了调整Redis的主要要点。
即使您不使用流水线处理，300个GET在150毫秒内并不十分高效。这意味着平均延迟为500微秒。但实际上，这取决于您对象的大小。对象越大，延迟就越高。在我的非常老旧的2GHz 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
它使用独特的连接方式而没有使用流水线技术，因此延迟可以从吞吐量中推导出来。尝试将这些基准测试结果与应用程序测量得到的数字进行比较。
您可能需要检查以下几点：
- 您使用哪个Redis客户端库？使用哪种开发语言？对于某些脚本语言，您需要安装hiredis模块以获得高效的客户端。
- 您的机器是虚拟机吗？使用哪个操作系统？
- Redis的连接是否持久？（即您不应在应用程序服务器的每个HTTP请求中连接/断开连接）。
为什么使用memcached更好？嗯，单个memcached实例肯定更具可扩展性，并且可能比单个Redis实例响应更快，因为它可以在多个线程上运行。Redis很快，但是单线程-所有命令的执行都是串行的。因此，当连接执行某个命令时，所有其他客户端都必须等待-给定命令的差延迟也会影响所有待处理命令。一般来说，在低吞吐量下，性能是相当可比的。
在每秒1000次查询（按Redis或memcached标准为低吞吐量）时，我认为您的问题更可能是客户端方面的问题（即客户端库的选择、连接/断开连接等），而不是Redis服务器本身的问题。
最后，我应该提到，如果您在每个HTTP请求中生成大量的Redis查询，请尽可能使用流水线技术管道化您发送到Redis的命令。这确实是开发高效Redis应用程序的关键点。
如果您的应用程序服务器与Redis在同一台机器上，则还可以使用Unix域套接字而不是TCP回环连接到Redis。它会略微提高性能（在不使用流水线技术时增加50%的吞吐量）。
