Lua FFI方式如何转换 struct in_addr * 到 struct in_addr？

wang287611200 · 2015-12-07T11:35:09+00:00

请注意MD5是很差的一个 Password Hash function, 用bcrypt或者scrypt，或&#x80...

Lua FFI方式如何转换 struct in_addr * 到 struct in_addr？

wang287611200

大家好：

我在使用lua FFI调用方法char *inet_ntoa (struct in_addr); 时，无法将 struct in_addr * 转换到struct in_addr，请问我需要怎么处理啊？

chenweidelphi

@agentzh,这个RANGE_Cache的LUA代码实现还是阻塞方式，不适合高并发大切片的场景，有什么优化思路么？

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

发件人: "王程";<wang28...@gmail.com>;

发送时间: 2015年12月7日(星期一) 中午11:35

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

主题: [openresty] Lua FFI方式如何转换 struct in_addr * 到 struct in_addr？

大家好：

我在使用lua FFI调用方法char *inet_ntoa (struct in_addr); 时，无法将 struct in_addr * 转换到struct in_addr，请问我需要怎么处理啊？

agentzh

Hello!

2015-12-06 19:35 GMT-08:00 王程:
>     我在使用lua FFI调用 方法char *inet_ntoa (struct in_addr); 时，无法将 struct in_addr *
> 转换到struct in_addr，请问我需要怎么处理啊？
>

假设你的 Lua 变量 a 的 cdata 的类型为 struct in_addr *，那么 a[0] 对应的 cdata
的类型则是你需要的 struct in_addr.

Regards,
-agentzh

agentzh

Hello!

2015-12-06 20:48 GMT-08:00 泡泡鱼:
> @agentzh,这个RANGE_Cache的LUA代码实现还是阻塞方式，不适合高并发大切片的场景，有什么优化思路么？
>

你是指哪个部分阻塞？如果是文件 IO 部分，可以使用 nginx 的内部 OS 线池程进行规避。

Regards,
-agentzh

chen.wei37

不是文件IO，content.lua的117行 local ok, code, headers, status, body = httpc:request(req_params)

对于一个WORKER来说是阻塞的，即使一收到部分body就转给终端一样会阻塞同一个worker上的其他终端用户。

是

陈伟 Chen Wei 多媒体业务产品部
	云计算及IT产品经营部
	Cloud Computing & IT Product Operation
1/F, Building No. 3, ZTE Corporation, Yuhuatai District, , Nanjing, P.R.China, 210012 Mobile: +86-18913979100 Email: chen...@zte.com.cn More Information: VAS 、Cloud

发件人: "Yichun Zhang (agentzh)" <age...@gmail.com>
收件人: openresty <openresty@googlegroups.com>,
日期: 2015/12/07 14:37
主题: Re: [openresty] http://syshero.org/post/77122862845/caching-range-requests-using-nginx-at-maxcdn
发件人: openresty@googlegroups.com

Hello! 2015-12-06 20:48 GMT-08:00 泡泡鱼: > @agentzh,这个RANGE_Cache的LUA代码实现还是阻塞方式，不适合高并发大切片的场景，有什么优化思路么？ > 你是指哪个部分阻塞？如果是文件 IO 部分，可以使用 nginx 的内部 OS 线池程进行规避。 Regards, -agentzh --


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

Attachment: ranger-master.zip
Description: Zip archive

agentzh

Hello!

2015-12-06 22:43 GMT-08:00 <chen...@zte.com.cn>:
>
> 不是文件IO，content.lua的117行        local ok, code, headers, status, body  = httpc:request(req_params)
>
> 对于一个WORKER来说是阻塞的，即使一收到部分body就转给终端一样会阻塞同一个worker上的其他终端用户。
>

貌似这里使用的是基于 cosocket API 的 lua-resty-http 库，所以其本身并不会阻塞 nginx
事件循环，也不会阻塞同一个 worker 里面的其他并发请求。

Regards,
-agentzh

chen.wei37

但是实际跟踪NGINX运行情况发现的确是阻塞了。

发件人: "Yichun Zhang (agentzh)" <age...@gmail.com>
收件人: openresty <openresty@googlegroups.com>,
日期: 2015/12/07 15:16
主题: Re: 答复: Re: [openresty] http://syshero.org/post/77122862845/caching-range-requests-using-nginx-at-maxcdn
发件人: openresty@googlegroups.com

Hello! 2015-12-06 22:43 GMT-08:00 <chen...@zte.com.cn>: > > 不是文件IO，content.lua的117行 local ok, code, headers, status, body = httpc:request(req_params) > > 对于一个WORKER来说是阻塞的，即使一收到部分body就转给终端一样会阻塞同一个worker上的其他终端用户。 > 貌似这里使用的是基于 cosocket API 的 lua-resty-http 库，所以其本身并不会阻塞 nginx 事件循环，也不会阻塞同一个 worker 里面的其他并发请求。 Regards, -agentzh --


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

agentzh

Hello!

2015-12-06 23:24 GMT-08:00 <chen...@zte.com.cn>:
>
> 但是实际跟踪NGINX运行情况发现的确是阻塞了。
>

你具体是如何跟踪的？阻塞操作的细节诊断使用 off-CPU time 火焰图工具是最合适的：

    https://openresty.org/#Profiling

一图胜千言 :)

Regards,
-agentzh

chen.wei37

#4 0x0000000000520c85 in ngx_http_lua_run_thread ()
#5 0x0000000000537849 in ngx_http_lua_socket_tcp_resume_helper ()
#6 0x000000000053771b in ngx_http_lua_socket_tcp_read_resume ()
#7 0x00000000005269da in ngx_http_lua_content_wev_handler ()
#8 0x00000000005336f7 in ngx_http_lua_socket_handle_read_success ()
#9 0x0000000000531c86 in ngx_http_lua_socket_tcp_read ()
#10 0x00000000005331e9 in ngx_http_lua_socket_read_handler ()
#11 0x00000000005330a6 in ngx_http_lua_socket_tcp_handler ()
#12 0x0000000000484846 in ngx_epoll_process_events ()
#13 0x000000000047381a in ngx_process_events_and_timers ()
#14 0x0000000000482065 in ngx_worker_process_cycle ()
#15 0x000000000047c12b in ngx_spawn_process ()
#16 0x0000000000480869 in ngx_start_worker_processes ()
#17 0x000000000047fe6f in ngx_master_process_cycle ()
#18 0x000000000044b152 in main ()

发件人: "Yichun Zhang (agentzh)" <age...@gmail.com>
收件人: openresty <openresty@googlegroups.com>,
日期: 2015/12/07 15:35
主题: Re: 答复: Re: 答复: Re: [openresty] http://syshero.org/post/77122862845/caching-range-requests-using-nginx-at-maxcdn
发件人: openresty@googlegroups.com

Hello! 2015-12-06 23:24 GMT-08:00 <chen...@zte.com.cn>: > > 但是实际跟踪NGINX运行情况发现的确是阻塞了。 > 你具体是如何跟踪的？阻塞操作的细节诊断使用 off-CPU time 火焰图工具是最合适的： https://openresty.org/#Profiling一图胜千言 :) Regards, -agentzh --


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

agentzh

Hello!

On Mon, Dec 7, 2015 at 12:22 AM, <chen...@zte.com.cn> wrote:
>
> #4  0x0000000000520c85 in ngx_http_lua_run_thread ()
> #5  0x0000000000537849 in ngx_http_lua_socket_tcp_resume_helper ()
> #6  0x000000000053771b in ngx_http_lua_socket_tcp_read_resume ()
> #7  0x00000000005269da in ngx_http_lua_content_wev_handler ()
> #8  0x00000000005336f7 in ngx_http_lua_socket_handle_read_success ()
> #9  0x0000000000531c86 in ngx_http_lua_socket_tcp_read ()
> #10 0x00000000005331e9 in ngx_http_lua_socket_read_handler ()
> #11 0x00000000005330a6 in ngx_http_lua_socket_tcp_handler ()
> #12 0x0000000000484846 in ngx_epoll_process_events ()
> #13 0x000000000047381a in ngx_process_events_and_timers ()
> #14 0x0000000000482065 in ngx_worker_process_cycle ()
> #15 0x000000000047c12b in ngx_spawn_process ()
> #16 0x0000000000480869 in ngx_start_worker_processes ()
> #17 0x000000000047fe6f in ngx_master_process_cycle ()
> #18 0x000000000044b152 in main ()
>

你得画出 off-CPU time 火焰图出来，咱对图进行讨论才有意义啊。光给一个 backtrace 说明不了什么问题的。

Regards,
-agentzh

chen.wei37

是这样的，跟踪发现一直在循环执行这部分API调用，正常情况这部分调用不会循环执行的。我的分析是事件触发的确没有阻塞，但是数据的处理被阻塞了。

实际情况就是同一个WORKER是一个进程，这个进程同一时间只能处理一个终端发过来的请求处理（这个处理我代码假定是代理100M的文件回源做PROXY_PASS）。

这个火焰图的使用方法我目前还没用过，可以学习怎么用了只后我发出来。

陈伟 Chen Wei 多媒体业务产品部
	云计算及IT产品经营部
	Cloud Computing & IT Product Operation
1/F, Building No. 3, ZTE Corporation, Yuhuatai District, , Nanjing, P.R.China, 210012 Mobile: +86-18913979100 Email: chen...@zte.com.cn More Information: VAS 、Cloud

发件人: "Yichun Zhang (agentzh)" <age...@gmail.com>
收件人: openresty <openresty@googlegroups.com>,
日期: 2015/12/07 16:25
主题: Re: 答复: Re: 答复: Re: 答复: Re: [openresty] http://syshero.org/post/77122862845/caching-range-requests-using-nginx-at-maxcdn
发件人: openresty@googlegroups.com

Hello! On Mon, Dec 7, 2015 at 12:22 AM, <chen...@zte.com.cn> wrote: > > #4 0x0000000000520c85 in ngx_http_lua_run_thread () > #5 0x0000000000537849 in ngx_http_lua_socket_tcp_resume_helper () > #6 0x000000000053771b in ngx_http_lua_socket_tcp_read_resume () > #7 0x00000000005269da in ngx_http_lua_content_wev_handler () > #8 0x00000000005336f7 in ngx_http_lua_socket_handle_read_success () > #9 0x0000000000531c86 in ngx_http_lua_socket_tcp_read () > #10 0x00000000005331e9 in ngx_http_lua_socket_read_handler () > #11 0x00000000005330a6 in ngx_http_lua_socket_tcp_handler () > #12 0x0000000000484846 in ngx_epoll_process_events () > #13 0x000000000047381a in ngx_process_events_and_timers () > #14 0x0000000000482065 in ngx_worker_process_cycle () > #15 0x000000000047c12b in ngx_spawn_process () > #16 0x0000000000480869 in ngx_start_worker_processes () > #17 0x000000000047fe6f in ngx_master_process_cycle () > #18 0x000000000044b152 in main () > 你得画出 off-CPU time 火焰图出来，咱对图进行讨论才有意义啊。光给一个 backtrace 说明不了什么问题的。 Regards, -agentzh --


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

agentzh

Hello!

On Mon, Dec 7, 2015 at 12:34 AM, <chen...@zte.com.cn> wrote:
>
> 是这样的，跟踪发现一直在循环执行这部分API调用，正常情况这部分调用不会循环执行的。我的分析是事件触发的确没有阻塞，但是数据的处理被阻塞了。
>

你需要首先检查你的 worker 进程的 CPU 占用。如果 CPU 很高，就上 on-CPU 火焰图；如果 CPU 总是上不去，就上
off-CPU 火焰图。如果你怀疑数据处理产生阻塞，那么 CPU 应当很高。

Regards,
-agentzh

wang287611200

谢谢，agentzh！通过这种方式获取不到！如下为我lua文件中的所有代码：

local ffi = require 'ffi'

ffi.cdef[[

typedef char * in_addr_t;

typedef struct

{

in_addr_t s_addr;

}in_addr;

typedef struct

{

char *h_name;

char **h_aliases;

int h_addrtype;

int h_length;

char **h_addr_list;

}hostent;

hostent *gethostbyname(const char *name);

char *inet_ntoa (struct in_addr);

int inet_aton(const char *cp, struct in_addr *inp);

int gethostname(char *name, size_t len);

]]

unction toip(hostname)

local hostent = ffi.C.gethostbyname(ngx.var.hostname)

local in_addr = ffi.cast('struct in_addr *',hostent.h_addr_list[0])

--local ip = ffi.C.inet_ntoa(in_addr)

ngx.say("result_code: "..ffi.string(hostent.h_name))

end

toip(gethostname())

以上代码在执行 inet_ntoa出错，按照你的方法还是不得其解，麻烦指导下，谢谢！

PS：我接触到的Lua FFI的相关知识都比较零散，请问有系统的学习资源么？
在 2015年12月7日星期一 UTC+8下午2:30:12，agentzh写道：

Hello!

2015-12-06 19:35 GMT-08:00 王程:
> 我在使用lua FFI调用方法char *inet_ntoa (struct in_addr); 时，无法将 struct in_addr *
> 转换到struct in_addr，请问我需要怎么处理啊？
>

假设你的 Lua 变量 a 的 cdata 的类型为 struct in_addr *，那么 a[0] 对应的 cdata
的类型则是你需要的 struct in_addr.

Regards,
-agentzh

agentzh

Hello!

2015-12-07 1:42 GMT-08:00 王程:
> PS：我接触到的Lua FFI的相关知识都比较零散，请问有系统的学习资源么？

建议仔细阅读 luajit.org 官网上 FFI 的用户手册和教程：

    http://luajit.org/

否则我只能代劳了，呵呵。

Regards,
-agentzh