shared big table constant

ming.zhang.china · 2014-03-01T12:30:04+00:00

Hello! On Mon, Mar 3, 2014 at 8:39 AM, wrote: > So if you don't know why the request > didn't work, don't reuse the connection by putting it back in...

shared big table constant

ming.zhang.china

Hi All

A performance and memory usage question.

I would like to pass configurations as a big complex table in a separate .lua file. the content will not be changed by workers at run time. the content might be changed by an external script and use SIGHUP to load new values.

so what is the best place to use it?

- in init_by_lua, load it as a module with global variables. since it is read only

- load by other code on demand and use it.

wonder which way is the right way? and faster way?

Thanks!

Ming

agentzh

Hello!

On Fri, Feb 28, 2014 at 8:30 PM, ming zhang wrote:
> I would like to pass configurations as a big complex table in a separate
> .lua file. the content will not be changed by workers at run time. the
> content might be changed by an external script and use SIGHUP to load new
> values.
> so what is the best place to use it?
> - in init_by_lua, load it as a module with global variables. since it is
> read only
> - load by other code on demand and use it.
>

Loading that Lua table in init_by_lua is the recommended approach
because the memory pages of the big read-only Lua table have a good
chance to be shared by all the worker processes forked from the
master. Thanks to the Copy-on-Write (COW) feature of modern operating
systems :)

Regards,
-agentzh