lua-resty-redis hgetall命令性能问题

lzm.aaron · 2015-07-06T18:14:10+00:00

Hello! 2015-07-06 15:10 GMT+08:00 <pengz...@gmail.com>: > 谢谢两个大大的回复，因...

lua-resty-redis hgetall命令性能问题

lzm.aaron

最近开发的一个项目中使用了咱们的openresty, 很不错

但是最近在使用redis中碰到了一个性能问题. 在redis的一个hash中有10w数据,key比较简单,就是1..100000, value比较复杂是json序列化的数据,数据格式为: "{\"to\":{\"y\":100,\"x\":100},\"u\":46747,\"met\":138899912,\"sid\":\"1\",\"mst\":138899912,\"dir\":1,\"from\":{\"y\":100,\"x\":100}}"

使用red:hgetall("test_hash")命令, 获取全部数据的时间很长,大概是90秒,这个测试是在虚拟机中测试的.

使用 red:hkeys("")命名,获取数据很快,秒取

我觉得这个时间还是有点问题.

能帮忙分析分析是什么样的问题吗?

多谢多谢

agentzh

Hello!

2015-07-06 18:14 GMT+08:00 aaron li:
> 最近开发的一个项目中使用了咱们的openresty, 很不错
> 但是最近在使用redis中碰到了一个性能问题. 在redis的一个hash中有10w数据,key比较简单,就是1..100000,
> value比较复杂是json序列化的数据,数据格式为:
> "{\"to\":{\"y\":100,\"x\":100},\"u\":46747,\"met\":138899912,\"sid\":\"1\",\"mst\":138899912,\"dir\":1,\"from\":{\"y\":100,\"x\":100}}"
>
> 使用red:hgetall("test_hash")命令, 获取全部数据的时间很长,大概是90秒,这个测试是在虚拟机中测试的.
> 使用 red:hkeys("")命名,获取数据很快,秒取
> 我觉得这个时间还是有点问题.
>

你的 redis 服务器和 nginx 都可能是瓶颈，建议使用 profiling
工具分别对二者进行分析（当然，分析前至少得观察一下各个进程的 CPU 使用率，对不？）：

https://openresty.org/#Profiling

没有实际的分析数据，光靠猜原因我是猜不出来的，呵呵。

Regards,
-agentzh

membphis

hello:

你的redis遍历方式最好修改一下。当被遍历对象比较大的时候，要使用redis的scan类方法。

我身边的同事，也同样被这个小细节坑过不少次。

推荐api：

http://redis.cn/commands/hscan.html

HSCAN key cursor [MATCH pattern] [COUNT count]

参考例子：

127.0.0.1:6379> hscan test 0

1) "17"

2) 1) "b"

2) "v"

3) "f"

4) "v"

5) "e"

6) "v"

7) "n"

8) "n"

9) "j"

10) "j"

127.0.0.1:6379> hscan test 17

1) "0"

2) 1) "h"

2) "h"

3) "i"

4) "i"

5) "a"

6) "v"

7) "Q"

8) "v"

这样你可以自己控制每次获取的量大小，梯阶的方式完成最终的递归。

@agentzh，这个API是否可以同步到ngx-dictionary里面，相比目前的ngx.shared.DICT.get_keys是否更安全一些？只要值得做，我们就先mark下，后面逐步实现。 :)

On Monday, July 6, 2015 at 6:14:10 PM UTC+8, aaron li wrote:

Hi

最近开发的一个项目中使用了咱们的openresty, 很不错
但是最近在使用redis中碰到了一个性能问题. 在redis的一个hash中有10w数据,key比较简单,就是1..100000, value比较复杂是json序列化的数据,数据格式为: "{\"to\":{\"y\":100,\"x\":100},\"u\":46747,\"met\":138899912,\"sid\":\"1\",\"mst\":138899912,\"dir\":1,\"from\":{\"y\":100,\"x\":100}}"

使用red:hgetall("test_hash")命令, 获取全部数据的时间很长,大概是90秒,这个测试是在虚拟机中测试的.
使用 red:hkeys("")命名,获取数据很快,秒取
我觉得这个时间还是有点问题.

能帮忙分析分析是什么样的问题吗?

多谢多谢

lzm.aaron

又用别的机器测试了一下,秒取. 应该是我虚拟机的问题, 抽空通过工具分析下具体什么问题

多谢!

在 2015年7月6日星期一 UTC+8下午6:22:34，agentzh写道：

Hello!

2015-07-06 18:14 GMT+08:00 aaron li:
> 最近开发的一个项目中使用了咱们的openresty, 很不错
> 但是最近在使用redis中碰到了一个性能问题. 在redis的一个hash中有10w数据,key比较简单,就是1..100000,
> value比较复杂是json序列化的数据,数据格式为:
> "{\"to\":{\"y\":100,\"x\":100},\"u\":46747,\"met\":138899912,\"sid\":\"1\",\"mst\":138899912,\"dir\":1,\"from\":{\"y\":100,\"x\":100}}"
>
> 使用red:hgetall("test_hash")命令, 获取全部数据的时间很长,大概是90秒,这个测试是在虚拟机中测试的.
> 使用 red:hkeys("")命名,获取数据很快,秒取
> 我觉得这个时间还是有点问题.
>

你的 redis 服务器和 nginx 都可能是瓶颈，建议使用 profiling
工具分别对二者进行分析（当然，分析前至少得观察一下各个进程的 CPU 使用率，对不？）：

https://openresty.org/#Profiling

没有实际的分析数据，光靠猜原因我是猜不出来的，呵呵。

Regards,
-agentzh

lzm.aaron

我也看到有人说redis的hgetall这个命令是个坑. HSCAN没用过,不知道具体性能怎么样, 我试下

多谢!

在 2015年7月6日星期一 UTC+8下午11:43:35，YuanSheng Wang写道：

hello:

你的redis遍历方式最好修改一下。当被遍历对象比较大的时候，要使用redis的scan类方法。

我身边的同事，也同样被这个小细节坑过不少次。

推荐api：
http://redis.cn/commands/hscan.html
HSCAN key cursor [MATCH pattern] [COUNT count]

参考例子：
127.0.0.1:6379> hscan test 0
1) "17"
2) 1) "b"
2) "v"
3) "f"
4) "v"
5) "e"
6) "v"
7) "n"
8) "n"
9) "j"
10) "j"
127.0.0.1:6379> hscan test 17
1) "0"
2) 1) "h"
2) "h"
3) "i"
4) "i"
5) "a"
6) "v"
7) "Q"
8) "v"

这样你可以自己控制每次获取的量大小，梯阶的方式完成最终的递归。

@agentzh，这个API是否可以同步到ngx-dictionary里面，相比目前的ngx.shared.DICT.get_keys是否更安全一些？只要值得做，我们就先mark下，后面逐步实现。 :)

On Monday, July 6, 2015 at 6:14:10 PM UTC+8, aaron li wrote:
Hi

最近开发的一个项目中使用了咱们的openresty, 很不错
但是最近在使用redis中碰到了一个性能问题. 在redis的一个hash中有10w数据,key比较简单,就是1..100000, value比较复杂是json序列化的数据,数据格式为: "{\"to\":{\"y\":100,\"x\":100},\"u\":46747,\"met\":138899912,\"sid\":\"1\",\"mst\":138899912,\"dir\":1,\"from\":{\"y\":100,\"x\":100}}"

使用red:hgetall("test_hash")命令, 获取全部数据的时间很长,大概是90秒,这个测试是在虚拟机中测试的.
使用 red:hkeys("")命名,获取数据很快,秒取
我觉得这个时间还是有点问题.

能帮忙分析分析是什么样的问题吗?

多谢多谢

在 2015年7月6日星期一 UTC+8下午11:43:35，YuanSheng Wang写道：

hello:

你的redis遍历方式最好修改一下。当被遍历对象比较大的时候，要使用redis的scan类方法。

我身边的同事，也同样被这个小细节坑过不少次。

推荐api：
http://redis.cn/commands/hscan.html
HSCAN key cursor [MATCH pattern] [COUNT count]

参考例子：
127.0.0.1:6379> hscan test 0
1) "17"
2) 1) "b"
2) "v"
3) "f"
4) "v"
5) "e"
6) "v"
7) "n"
8) "n"
9) "j"
10) "j"
127.0.0.1:6379> hscan test 17
1) "0"
2) 1) "h"
2) "h"
3) "i"
4) "i"
5) "a"
6) "v"
7) "Q"
8) "v"

这样你可以自己控制每次获取的量大小，梯阶的方式完成最终的递归。

@agentzh，这个API是否可以同步到ngx-dictionary里面，相比目前的ngx.shared.DICT.get_keys是否更安全一些？只要值得做，我们就先mark下，后面逐步实现。 :)

On Monday, July 6, 2015 at 6:14:10 PM UTC+8, aaron li wrote:
Hi

最近开发的一个项目中使用了咱们的openresty, 很不错
但是最近在使用redis中碰到了一个性能问题. 在redis的一个hash中有10w数据,key比较简单,就是1..100000, value比较复杂是json序列化的数据,数据格式为: "{\"to\":{\"y\":100,\"x\":100},\"u\":46747,\"met\":138899912,\"sid\":\"1\",\"mst\":138899912,\"dir\":1,\"from\":{\"y\":100,\"x\":100}}"

使用red:hgetall("test_hash")命令, 获取全部数据的时间很长,大概是90秒,这个测试是在虚拟机中测试的.
使用 red:hkeys("")命名,获取数据很快,秒取
我觉得这个时间还是有点问题.

能帮忙分析分析是什么样的问题吗?

多谢多谢

在 2015年7月6日星期一 UTC+8下午11:43:35，YuanSheng Wang写道：

hello:

你的redis遍历方式最好修改一下。当被遍历对象比较大的时候，要使用redis的scan类方法。

我身边的同事，也同样被这个小细节坑过不少次。

推荐api：
http://redis.cn/commands/hscan.html
HSCAN key cursor [MATCH pattern] [COUNT count]

参考例子：
127.0.0.1:6379> hscan test 0
1) "17"
2) 1) "b"
2) "v"
3) "f"
4) "v"
5) "e"
6) "v"
7) "n"
8) "n"
9) "j"
10) "j"
127.0.0.1:6379> hscan test 17
1) "0"
2) 1) "h"
2) "h"
3) "i"
4) "i"
5) "a"
6) "v"
7) "Q"
8) "v"

这样你可以自己控制每次获取的量大小，梯阶的方式完成最终的递归。

@agentzh，这个API是否可以同步到ngx-dictionary里面，相比目前的ngx.shared.DICT.get_keys是否更安全一些？只要值得做，我们就先mark下，后面逐步实现。 :)

On Monday, July 6, 2015 at 6:14:10 PM UTC+8, aaron li wrote:
Hi

最近开发的一个项目中使用了咱们的openresty, 很不错
但是最近在使用redis中碰到了一个性能问题. 在redis的一个hash中有10w数据,key比较简单,就是1..100000, value比较复杂是json序列化的数据,数据格式为: "{\"to\":{\"y\":100,\"x\":100},\"u\":46747,\"met\":138899912,\"sid\":\"1\",\"mst\":138899912,\"dir\":1,\"from\":{\"y\":100,\"x\":100}}"

使用red:hgetall("test_hash")命令, 获取全部数据的时间很长,大概是90秒,这个测试是在虚拟机中测试的.
使用 red:hkeys("")命名,获取数据很快,秒取
我觉得这个时间还是有点问题.

能帮忙分析分析是什么样的问题吗?

多谢多谢