回复：[openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

chenweidelphi

是啊，说的太对了。这是个高频操作，希望能高性能。

------------------ 原始邮件 ------------------

发件人: Ming <moonb...@gmail.com>

发送时间: 2015年12月25日 18:41

收件人: openresty@googlegroups.com <openresty@googlegroups.com>

抄送: DeJiang Zhu <douj...@gmail.com>

主题: Re: [openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

如果能直接储存lua的对象，像resty-lrucache一样，就省去了序列号和反序列化的消耗。@泡泡鱼是这个意思吗？

2015-12-25 18:23 GMT+08:00 YuanSheng Wang <mem...@gmail.com>:

如果在 dict 里面存储的是结构体，那么结构体的序列化、反序列化就会是个麻烦（复杂度，读取、写入效率，都不是那么容易）。

看看其他数据库产品，memcached、redis 都没有这么干的。他们的演化方向都是通过扩充 API 来达到这个目的。

春哥明年的功能展望，会对 shdict 添加 redis style 的 api，这些东西刚好是楼上德江同学努力的东东。 ^_^

On Fri, Dec 25, 2015 at 6:16 PM, 泡泡鱼 <chenwe...@qq.com> wrote:
就是目前看起来只能操作字符串类型，是不是可以操作table或者你说的类似c结构体这样的复合类型？
发自我的iPhone

------------------ 原始邮件 ------------------
发件人: DeJiang Zhu <douj...@gmail.com>
发送时间: 2015年12月25日 17:04
收件人: openresty <openresty@googlegroups.com>
主题: Re: [openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

Hello，

不太清楚你说的结构体是什么意思

值得一提的是，resty.limit.req 里有一种玩法是，直接把一个 C struct （LuaJIT 的 cdata）当做 value 传入
https://github.com/openresty/lua-resty-limit-traffic/blob/master/lib/resty/limit/req.lua#L24

2015-12-25 12:44 GMT+08:00 泡泡鱼 <chenwe...@qq.com>:

--

--
--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices
--

chenweidelphi

resty-lrucache我看教程也只是VALUE为字符串啊，能是结构或对象么？

我想字典对象能有这个功能的初衷就来源于ngx_realtime_request_module这样的统计功能，觉得用LUA实现就够了，没必要用C写模块实现。无奈在C里面可以用到一些原子操作的支持，在LUA里如果序列化和反序列化则显得消耗太大。

------------------ 原始邮件 ------------------

发件人: "泡泡鱼";<chenwe...@qq.com>;

发送时间: 2015年12月25日(星期五) 晚上6:50

收件人: "Ming"<moonb...@gmail.com>; "openresty"<openresty@googlegroups.com>;

抄送: "DeJiang Zhu"<douj...@gmail.com>;

主题: 回复：[openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

是啊，说的太对了。这是个高频操作，希望能高性能。

------------------ 原始邮件 ------------------

发件人: Ming <moonb...@gmail.com>

发送时间: 2015年12月25日 18:41

收件人: openresty@googlegroups.com <openresty@googlegroups.com>

抄送: DeJiang Zhu <douj...@gmail.com>

主题: Re: [openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

如果能直接储存lua的对象，像resty-lrucache一样，就省去了序列号和反序列化的消耗。@泡泡鱼是这个意思吗？

2015-12-25 18:23 GMT+08:00 YuanSheng Wang <mem...@gmail.com>:

如果在 dict 里面存储的是结构体，那么结构体的序列化、反序列化就会是个麻烦（复杂度，读取、写入效率，都不是那么容易）。

看看其他数据库产品，memcached、redis 都没有这么干的。他们的演化方向都是通过扩充 API 来达到这个目的。

春哥明年的功能展望，会对 shdict 添加 redis style 的 api，这些东西刚好是楼上德江同学努力的东东。 ^_^

On Fri, Dec 25, 2015 at 6:16 PM, 泡泡鱼 <chenwe...@qq.com> wrote:
就是目前看起来只能操作字符串类型，是不是可以操作table或者你说的类似c结构体这样的复合类型？
发自我的iPhone

------------------ 原始邮件 ------------------
发件人: DeJiang Zhu <douj...@gmail.com>
发送时间: 2015年12月25日 17:04
收件人: openresty <openresty@googlegroups.com>
主题: Re: [openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

Hello，

不太清楚你说的结构体是什么意思

值得一提的是，resty.limit.req 里有一种玩法是，直接把一个 C struct （LuaJIT 的 cdata）当做 value 传入
https://github.com/openresty/lua-resty-limit-traffic/blob/master/lib/resty/limit/req.lua#L24

2015-12-25 12:44 GMT+08:00 泡泡鱼 <chenwe...@qq.com>:

--

--
--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices
--

Attachment: ngx_realtime_request_module.c
Description: Binary data

chenweidelphi

resty-lrucache我又看了下文档说明，文档上写是可以支持LUA对象，但是又说作用域是worker级别的，这点用于全局统计又有点头疼。

------------------ 原始邮件 ------------------

发件人: "泡泡鱼";<chenwe...@qq.com>;

发送时间: 2015年12月26日(星期六) 晚上8:31

收件人: "Ming"<moonb...@gmail.com>; "openresty"<openresty@googlegroups.com>;

抄送: "DeJiang Zhu"<douj...@gmail.com>;

主题: 回复：[openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

resty-lrucache我看教程也只是VALUE为字符串啊，能是结构或对象么？

------------------ 原始邮件 ------------------

发件人: "泡泡鱼";<chenwe...@qq.com>;

发送时间: 2015年12月25日(星期五) 晚上6:50

收件人: "Ming"<moonb...@gmail.com>; "openresty"<openresty@googlegroups.com>;

抄送: "DeJiang Zhu"<douj...@gmail.com>;

主题: 回复：[openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

是啊，说的太对了。这是个高频操作，希望能高性能。

------------------ 原始邮件 ------------------

发件人: Ming <moonb...@gmail.com>

发送时间: 2015年12月25日 18:41

收件人: openresty@googlegroups.com <openresty@googlegroups.com>

抄送: DeJiang Zhu <douj...@gmail.com>

主题: Re: [openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

如果能直接储存lua的对象，像resty-lrucache一样，就省去了序列号和反序列化的消耗。@泡泡鱼是这个意思吗？

2015-12-25 18:23 GMT+08:00 YuanSheng Wang <mem...@gmail.com>:

如果在 dict 里面存储的是结构体，那么结构体的序列化、反序列化就会是个麻烦（复杂度，读取、写入效率，都不是那么容易）。

看看其他数据库产品，memcached、redis 都没有这么干的。他们的演化方向都是通过扩充 API 来达到这个目的。

春哥明年的功能展望，会对 shdict 添加 redis style 的 api，这些东西刚好是楼上德江同学努力的东东。 ^_^

On Fri, Dec 25, 2015 at 6:16 PM, 泡泡鱼 <chenwe...@qq.com> wrote:
就是目前看起来只能操作字符串类型，是不是可以操作table或者你说的类似c结构体这样的复合类型？
发自我的iPhone

------------------ 原始邮件 ------------------
发件人: DeJiang Zhu <douj...@gmail.com>
发送时间: 2015年12月25日 17:04
收件人: openresty <openresty@googlegroups.com>
主题: Re: [openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

Hello，

不太清楚你说的结构体是什么意思

值得一提的是，resty.limit.req 里有一种玩法是，直接把一个 C struct （LuaJIT 的 cdata）当做 value 传入
https://github.com/openresty/lua-resty-limit-traffic/blob/master/lib/resty/limit/req.lua#L24

2015-12-25 12:44 GMT+08:00 泡泡鱼 <chenwe...@qq.com>:

--

--
--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices
--

chenweidelphi

https://www.centos.bz/2015/09/openresty-nginx-lua-count-status-flow-request-time/

参考这篇文章：（实在不想用这种方式去实现，其实只要找一次KEY就可以设置多个值，而下面实现则需要每个值都要GET一次）

log_access.lua

local access = ngx.shared.access
local host = ngx.var.host
local status = ngx.var.status
local body_bytes_sent = ngx.var.body_bytes_sent
local request_time = ngx.var.request_time
local timestamp = os.date("%s")
local expire_time = 70
 
local status_key = table.concat({host,"-",status,"-",timestamp})
local flow_key = table.concat({host,"-flow-",timestamp})
local req_time_key = table.concat({host,"-reqt-",timestamp})
local total_req_key = table.concat({host,"-total_req-",timestamp})
 
-- count total req
local total_req_sum = access:get(total_req_key) or 0
total_req_sum = total_req_sum + 1
access:set(total_req_key, total_req_sum, expire_time)
 
-- count status
local status_sum = access:get(status_key) or 0
status_sum = status_sum + 1
access:set(status_key, status_sum, expire_time)
 
-- count flow
local flow_sum = access:get(flow_key) or 0
flow_sum = flow_sum + body_bytes_sent
access:set(flow_key, flow_sum, expire_time)
 
-- count request time
local req_sum = access:get(req_time_key) or 0
req_sum = req_sum + request_time
access:set(req_time_key, req_sum, expire_time)

------------------ 原始邮件 ------------------

发件人: "泡泡鱼";<chenwe...@qq.com>;

发送时间: 2015年12月26日(星期六) 晚上9:23

收件人: "Ming"<moonb...@gmail.com>; "openresty"<openresty@googlegroups.com>;

抄送: "DeJiang Zhu"<douj...@gmail.com>;

主题: 回复：[openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

resty-lrucache我又看了下文档说明，文档上写是可以支持LUA对象，但是又说作用域是worker级别的，这点用于全局统计又有点头疼。

------------------ 原始邮件 ------------------

发件人: "泡泡鱼";<chenwe...@qq.com>;

发送时间: 2015年12月26日(星期六) 晚上8:31

收件人: "Ming"<moonb...@gmail.com>; "openresty"<openresty@googlegroups.com>;

抄送: "DeJiang Zhu"<douj...@gmail.com>;

主题: 回复：[openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

resty-lrucache我看教程也只是VALUE为字符串啊，能是结构或对象么？

------------------ 原始邮件 ------------------

发件人: "泡泡鱼";<chenwe...@qq.com>;

发送时间: 2015年12月25日(星期五) 晚上6:50

收件人: "Ming"<moonb...@gmail.com>; "openresty"<openresty@googlegroups.com>;

抄送: "DeJiang Zhu"<douj...@gmail.com>;

主题: 回复：[openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

是啊，说的太对了。这是个高频操作，希望能高性能。

------------------ 原始邮件 ------------------

发件人: Ming <moonb...@gmail.com>

发送时间: 2015年12月25日 18:41

收件人: openresty@googlegroups.com <openresty@googlegroups.com>

抄送: DeJiang Zhu <douj...@gmail.com>

主题: Re: [openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

如果能直接储存lua的对象，像resty-lrucache一样，就省去了序列号和反序列化的消耗。@泡泡鱼是这个意思吗？

2015-12-25 18:23 GMT+08:00 YuanSheng Wang <mem...@gmail.com>:

如果在 dict 里面存储的是结构体，那么结构体的序列化、反序列化就会是个麻烦（复杂度，读取、写入效率，都不是那么容易）。

看看其他数据库产品，memcached、redis 都没有这么干的。他们的演化方向都是通过扩充 API 来达到这个目的。

春哥明年的功能展望，会对 shdict 添加 redis style 的 api，这些东西刚好是楼上德江同学努力的东东。 ^_^

On Fri, Dec 25, 2015 at 6:16 PM, 泡泡鱼 <chenwe...@qq.com> wrote:
就是目前看起来只能操作字符串类型，是不是可以操作table或者你说的类似c结构体这样的复合类型？
发自我的iPhone

------------------ 原始邮件 ------------------
发件人: DeJiang Zhu <douj...@gmail.com>
发送时间: 2015年12月25日 17:04
收件人: openresty <openresty@googlegroups.com>
主题: Re: [openresty] ngx.shared.DICT里面的value能否实现为一个结构体，这样做统计的时候会方便很多

Hello，

不太清楚你说的结构体是什么意思

值得一提的是，resty.limit.req 里有一种玩法是，直接把一个 C struct （LuaJIT 的 cdata）当做 value 传入
https://github.com/openresty/lua-resty-limit-traffic/blob/master/lib/resty/limit/req.lua#L24

2015-12-25 12:44 GMT+08:00 泡泡鱼 <chenwe...@qq.com>:

--

--
--

--

Membhis
My github: https://github.com/membphis
Our Book: OpenResty Best Practices
--

agentzh

Hello!

2015-12-26 4:31 GMT-08:00 泡泡鱼:
> resty-lrucache我看教程也只是VALUE为字符串啊，能是结构或对象么？

引用一下 lua-resty-lrucache 官方文档中对此的说明：

“The LRU cache resides completely in the Lua VM and is subject to Lua
GC. So do not expect it to get shared across the OS process boundary.
The upside is that you can cache arbitrary complex Lua values (like
deep nested Lua tables) without the overhead of serialization (as with
ngx_lua's shared dictionary API). The downside is that your cache is
always limited to the current OS process (like the current nginx
worker process).
"

显然，任意的 Lua value 都可以作为缓存的值，甚至包括 Lua function 对象和 Lua thread 对象。

一般地，如果是作为缓存，我们使用 lua-resty-lrucache 和 lua_shared_dict
作两层缓存，前者避免序列化和反序列化，后者避免每个 worker 重复去远方数据源进行加载。当缓存命中率较高时，效果非常好。

对于你的统计用法，将每个结构体的字段展开为遍平的字段更为合适，比如使用 key:field 这种作为
key，缺点是当共享内存不够用时，会造成结构体的某个字段缺失。另外，lua_shared_dict 未来会支持 hash-table
类型的值（类似 redis 那种风格），届时应该会更加合适。

Regards,
-agentzh

agentzh

Hello!

2015-12-26 5:55 GMT-08:00 泡泡鱼:
> local timestamp = os.date("%s")

永远不要使用 os.date()，因为它通常会触发一到两次昂贵的系统调用，从而成为性能瓶颈。你这里可以直接使用 ngx_lua 提供的
ngx.time() 函数，这个函数是带时间缓存的，不会涉及任何系统调用。

> local expire_time = 70
>
> local status_key = table.concat({host,"-",status,"-",timestamp})

这一行拼串代码其实使用下面这种形式性能更高：

    local status_key = host .. "-" .. status .. "-" .. timestamp

Regards,
-agentzh