How to get async functionality in ffi and c in openresty.

aashish.aadhav · 2014-08-05T18:24:45+00:00

Hello! On Mon, Aug 4, 2014 at 2:20 PM, info wrote: > Hello agentzh, can I have a basic example for 1 and 2 ? > Please check out the relevant documen...

How to get async functionality in ffi and c in openresty.

aashish.aadhav

Hi ,
In my previous question I had enquired about using languauges other than lua [ c/c++] for open resty.
Accordingly I am using the ffi approach , writing .so and loading them via lua.
But the problem is I am not able to get async behavior , that can be obtained by using lua or inbuilt modules .

like for example

ngx.sleep

handles the sleep asynchornously .
I want to achieve this in C for curl , file io , etc .
How can I achieve this ?

Thanks and regards
--AshishA

agentzh

Hello!

On Tue, Aug 5, 2014 at 3:24 AM, ashish adhav wrote:
> In my previous question I had enquired about using languauges other than lua
> [ c/c++] for open resty.
> Accordingly I am using the ffi  approach , writing .so and loading them via
> lua.
> But the problem is I am not able to get async behavior , that can be
> obtained by using lua or inbuilt modules .
[...]
> handles the sleep asynchornously .
> I want to achieve this in  C  for curl , file io , etc .

Use the Lua API provided by ngx_lua to do I/O. For example, use the
cosocket API to do network I/O:

    https://github.com/openresty/lua-nginx-module#ngxsockettcp

    https://github.com/openresty/lua-nginx-module#ngxsocketudp

Only use C/FFI for CPU-bound calculations (and that's where native
code can really shine).

Regarding file I/O, there is no nonblocking file I/O at least in
Linux. Usually nginx itself just uses blocking I/O itself in many
places as long as the blocking period is expected to be small enough
(and yeah, do not use slow disks). Nginx also supports native AIO but
it's quite limited (and broken) on Linux at least but it can still be
a fun project to expose the AIO API to the Lua land in ngx_lua
(patches welcome :)). Another common work-around is to introduce extra
OS threads to handle blocking file I/O operations and it can also be
an interesting feature to explore in ngx_lua though OS threads have
their own nontrivial overhead and complexity. Yet another common
solution is to put massive file I/O operations into a dedicated daemon
server and let nginx talk to it over sockets instead.

Regards,
-agentzh

aashish.aadhav

Hello !

First of all thank you for your reply.
I was able to achieve 25 % performance improvement ( !!!! ) using openresty and also significant reduction in lines of code .

I wanted to know if we can achieve aynchronous behavior if we use c as the glu for lua code.
I intend to use the existing lua resty modules like redis , mysql and wrap them inside C . ( Actually I have to use C as we have developed many core libraries for my application )
Is this possible ?

Thanks for your time,
--AshishA

On Wednesday, August 6, 2014 12:34:01 AM UTC+5:30, agentzh wrote:

Hello!

On Tue, Aug 5, 2014 at 3:24 AM, ashish adhav wrote:
> In my previous question I had enquired about using languauges other than lua
> [ c/c++] for open resty.
> Accordingly I am using the ffi approach , writing .so and loading them via
> lua.
> But the problem is I am not able to get async behavior , that can be
> obtained by using lua or inbuilt modules .
[...]
> handles the sleep asynchornously .
> I want to achieve this in C for curl , file io , etc .

Use the Lua API provided by ngx_lua to do I/O. For example, use the
cosocket API to do network I/O:

https://github.com/openresty/lua-nginx-module#ngxsockettcp

https://github.com/openresty/lua-nginx-module#ngxsocketudp

Only use C/FFI for CPU-bound calculations (and that's where native
code can really shine).

Regarding file I/O, there is no nonblocking file I/O at least in
Linux. Usually nginx itself just uses blocking I/O itself in many
places as long as the blocking period is expected to be small enough
(and yeah, do not use slow disks). Nginx also supports native AIO but
it's quite limited (and broken) on Linux at least but it can still be
a fun project to expose the AIO API to the Lua land in ngx_lua
(patches welcome :)). Another common work-around is to introduce extra
OS threads to handle blocking file I/O operations and it can also be
an interesting feature to explore in ngx_lua though OS threads have
their own nontrivial overhead and complexity. Yet another common
solution is to put massive file I/O operations into a dedicated daemon
server and let nginx talk to it over sockets instead.

Regards,
-agentzh

agentzh

Hello!

On Mon, Aug 18, 2014 at 4:50 AM, ashish adhav wrote:
> First of all thank you for your reply.
> I was able to achieve 25 % performance improvement ( !!!! ) using openresty
> and also  significant reduction in lines of code .
>

Yay! Maybe you can also sample some flame graphs to squeeze more
performance out of it:

    https://github.com/agentzh/nginx-systemtap-toolkit#sample-bt

    https://github.com/openresty/nginx-systemtap-toolkit#sample-bt-off-cpu

    https://github.com/openresty/stapxx#lj-lua-stacks

We've been heavily relying on these tools to profile in production and
it's not uncommon to half the execution time of the whole app. (Also
just recently I quickly made gdb's builtin python extension 100%
faster for one of our CPU-bound gdb command written in Python, by just
looking at its on-CPU flame graphs generated by the sample-bt tool
above).

Optimizations can be very effective when you know exactly where you
should look at.

> I wanted to know if we can achieve aynchronous behavior if we use c as the
> glu for lua code.

Unfortunately C is not good at being a glue language. A more promising
approach is to get more of your Lua code *actually* JIT compiled ;)

> I intend to use the existing lua resty modules like redis , mysql and wrap
> them inside C . ( Actually I have to use C as we have developed many core
> libraries for my application  )
> Is this possible ?
>

Trust me, this is not the right way to go and you may finally find no
real gain after having spent too much resources on this approach.

On the other hand, you're welcome to contribute more lua-resty-*
libraries based on the cosocket API. It can be much much easier (and
also much more flexible) than trying to reuse your existing C drivers
in the context of NGINX.

Only optimize things according to your flame graphs ;) Otherwise it
will almost always be premature :)

Regards,
-agentzh