1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
Source: lua-resty-lrucache
Section: net
Priority: optional
Build-Depends:
debhelper-compat (= 13),
dh-lua,
Maintainer: Debian Lua Team <pkg-lua-devel@lists.alioth.debian.org>
Uploaders:
Jan Mojžíš <janmojzis@debian.org>,
Homepage: https://github.com/openresty/lua-resty-lrucache
Standards-Version: 4.7.0
Rules-Requires-Root: no
Vcs-Git: https://salsa.debian.org/lua-team/lua-resty-lrucache.git
Vcs-Browser: https://salsa.debian.org/lua-team/lua-resty-lrucache
Package: lua-resty-lrucache
Depends:
libluajit-5.1-2,
${misc:Depends},
${shlibs:Depends},
Provides:
${lua:Provides},
Architecture: all
Description: Simple LRU cache for the ngx_lua module
The LRU cache resides completely in the Lua VM and is subject to Lua GC.
As such, do not expect it to get shared across the OS process boundary.
The upside is that you can cache arbitrary complex Lua values (such as deep
nested Lua tables) without the overhead of serialization (as with ngx_lua's
shared dictionary API). The downside is that your cache is always limited to
the current OS process (i.e. the current Nginx worker process). It does not
really make much sense to use this library in the context of init_by_lua
because the cache will not get shared by any of the worker processes (unless
you just want to "warm up" the cache with predefined items which will
get inherited by the workers via fork()).
|
