Redis 性能问题？答案

【问题标题】：Redis performance issues?Redis 性能问题？
【发布时间】：2012-10-25 22:33:05
【问题描述】：

我试图在我的 Redis 上施加一些繁重的负载以进行测试并找出任何上限。首先，我加载了 50,000 和 100,000 个大小为 32 个字符的键，其值约为 32 个字符。两种密钥大小的时间都不超过 8-15 秒。现在我尝试将 4kb 的数据作为每个键的值。前 10000 个键需要 800 毫秒来设置。但从那时起，它逐渐变慢，设置整个 50,000 个键大约需要 40 分钟。我正在使用带有 node_redis (Mranney) 的 NodeJs 加载数据库。是我做错了什么，还是 Redis 在 4 KB 的大值下那么慢？

我现在发现的另一件事是，当我运行与当前客户端并行的另一个客户端并更新密钥时，第二个客户端在 8 秒内完成加载 50000 个具有 4kb 值的密钥，而第一个客户端仍然永远做它的事情。它是节点还是redis库中的错误？这是令人震惊的，不能用于生产。

【问题讨论】：

嗯.. 我安装了hiredis，但我不知道当我需要（'redis'）时它是否会自动加载到程序中。是这个问题吗？
验证是否安装了hiredis模块，可以运行node，然后require ("hiredis")。

标签： performance node.js redis

【解决方案1】：

在从节点向 Redis 进行批量写入时，您需要获得某种背压。默认情况下，节点会将所有写入排队，并且不会对传出队列大小强制设置上限。

node_redis 有一个“drain”事件，你可以监听它来实现一些基本的背压。

【讨论】：

嗨，马特，我试图查看 client.command_queue.length 并停止，直到我收到“drain”事件。但是 client.command_queue.length 始终为 0。所以我检查了 client.offline_queue.length ，它给了我正确的数字，但排水事件只被触发一次。我会再试一次并返回代码。谢谢。
我已在此处附上代码gist.github.com/945441。这似乎不是背压的正确方法？
这里有几个不同的问题。首先是预连接命令排队。第二个是一旦您建立了连接，就会为已发送但尚未收到回复的命令维护另一个队列。我在这里添加了处理这两种情况的一般方法示例：github.com/mranney/node_redis/blob/master/examples/…

【解决方案2】：

默认的 redis 配置没有针对这种使用进行优化。我怀疑您将其交换到页面大小为 32 字节的磁盘，这意味着添加的每个键都必须找到 128 个连续的空闲页面，并且最终可能会使用系统 VM 或需要大量扩展交换文件。

更新密钥时，空间已分配，因此您看不到任何性能问题。

【讨论】：

这只是为了测试目的，所以我不太在意。但是，如果这种需求是实时发生的，而我的应用程序需要存储这么多数据怎么办？我可以更改任何配置以满足我的要求吗？
即使在第一个客户端创建所有 50000 个密钥之前，如果我运行第二个客户端，它也会继续并在第一个客户端之前完成。所以你说的可能不是我面临的问题。
页面大小和内存使用是可配置的 - 检查 redis.conf 中的 cmets。第二个客户端完成并不一定排除这种情况 - 低内存条件和并发性的组合可能会变得相当复杂，尤其是在涉及超时和自动重试的情况下。例如，它是否会在每次遇到错误时重置所有以前的键？
嗯..它可能是！将研究这个问题。因为我的应用程序需要处理存储在 redis 数据库中的许多并发会话，我不能允许这种不确定性:(.

【解决方案3】：

由于我在 NodeJs 中进行了很多异步设置（键值），因此很多套接字连接同时打开。 NodeJs 套接字写入缓冲区可能会过载，并且 GC 可能会出现并摆弄节点进程。

PS：我按照 Tom 的建议更改了 redis 内存配置，但它仍然执行相同的操作。

【讨论】：