Re: [ANN] lua-resty-template -- a compiling templating engine for Lua

As far as I know, you may use either init_by_lua or init_worker_by_lua to warmup the cache. Or just let the cache warm up on the first request that uses the template. Lua will always return the same table when you do require "resty.template" (unless you also do package.loaded["resty.template"] = nil). Even on different requests on Nginx. So they always use the same cache table too. Now that I mentioned init_by_lua, I started to think that would this make it possible have a shared cache between all nginx workers (e.g. init_by_lua 'template = require "resty.template"'; and then in say content_by_lua 'local template = template';). I have to test this.

9.3.2014 8.40 kirjoitti "Hao Wu" <wuhao.wise@gmail.com>:

On Sat, Mar 8, 2014 at 6:27 AM, Aapo Talvensaari
<aapo.talvensaari@gmail.com> wrote:
> Hi,
>
> If by context you mean user supplied context table, e.g.
> template.render("test.html", { context_value = "test" }), you are correct
> that the result of this call is not cached, but the actual function that is
> generated from test.html is cached (by default). So, the cached function can
> be called with many different context tables. If you also want to cache the
> results, you can do it like this: local res = template.compile("test.html"){
> context_value = "test" }. Then just store the res string in somewhere (e.g.
> in memory, file or redis).
>
> But if by context you mean actual Lua process, the cache is not shared
> between them. And I do not think that it can be easily done, as the cache
> actually holds Lua functions. On Nginx / OpenResty context this means that
> each Nginx worker has their own Lua VM, so the cache is local to Nginx
> worker. If you have two Nginx worker processes each template function is
> cached twice (if these workers run the same code). You may also disable
> caching with template.caching(false). I'm also going to add support for set
> $template_caching 0|1; for Nginx, so that you can easily disable caching in
> Nginx configuration (many may want to have caching disabled on development
> env).

Thanks for clarifying this, and this is what I meant. I looked up the
ngx_lua module, it vaguely talked about how the lua state is
maintained across the workers' process; but if you are right, would it
be possible to use init_worker_by_lua directive to initialize global
variables (i.e. the caching table) so that at least the caching would
be shared per-process. This is probably what you are already doing...

I guess this mailing list is probably not a good thread to talk about
openresty in details though...

>
> Regards
> Aapo
>
> 8.3.2014 8.43 kirjoitti "Hao Wu" <wuhao.wise@gmail.com>:
>
>> Hi Aapo,
>>
>> The benchmark seems to be running without switching contexts; in the
>> real environment, if there are hundreds of requests, the contexts
>> won't be shared so the cache will actually not be used? Or am I
>> missing something?
>>
>> ~Hao
>>
>>
>> On Fri, Mar 7, 2014 at 8:56 AM, Aapo Talvensaari
>> <aapo.talvensaari@gmail.com> wrote:
>> > My (HTML) templating engine for Lua with special support for Nginx /
>> > OpenResty (HttpLuaModule):
>> >
>> > https://github.com/bungle/lua-resty-template/
>> >
>> > I started this for my own needs. I shortly looked at other alternatives
>> > in
>> > templating (https://github.com/bungle/lua-resty-template/#alternatives),
>> > but
>> > I though that there was a room for another implementation. The syntax
>> > should
>> > be familiar (not 1:1) to anyone who has worked with things like Mustache
>> > (http://mustache.github.io/) or say PHP.
>> >
>> > I feel that the codebase is quite stable, and the performance is good
>> > (especially the cached performance). I also think that the API is clean,
>> > while still allowing some extensions / overwrites for flexibility. I
>> > have
>> > not yet made automated unit tests or integrated this with LuaRocks. At
>> > this
>> > point I wish to receive feedback. The code is fully Lua 5.2 and LuaJIT
>> > 2.x
>> > compatible. It doesn't work with Lua 5.1 as the 5.1 version of
>> > load-function
>> > is different. It could be made to work with 5.1 using setfenv, but that
>> > is
>> > not on my agenda (if I don't get enough feedback to add support for it).
>> > Feel free to fork it, if you need 5.1 support, or send me a pull request
>> > if
>> > you have managed to make things work on 5.1 (and even earlier versions).
>> >
>> > So, please take a look at it on Github (it's fairly well documented
>> > there).
>> >
>> >
>> > Regards
>> > Aapo
>>
>