 |
lua-l archive |
|
|
||
|
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).
Regards
Aapo
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