| Description: | One of once, request, conn, thread -- default is once |
|---|
| Syntax: | LuaScope once|request|conn|thread|server [min] [max] |
|---|
| Default: | LuaScope once |
|---|
| Context: | server config, virtual host, directory, .htaccess |
|---|
| Override: | All |
|---|
| Status: | Experimental |
|---|
| Module: | mod_lua |
|---|
Specify the life cycle scope of the Lua interpreter which will
be used by handlers in this "Directory." The default is "once"
- once:
- use the interpreter once and throw it away.
- request:
- use the interpreter to handle anything based on
the same file within this request, which is also
request scoped.
- conn:
- Same as request but attached to the connection_rec
- thread:
- Use the interpreter for the lifetime of the thread
handling the request (only available with threaded MPMs).
- server:
- This one is different than others because the
server scope is quite long lived, and multiple threads
will have the same server_rec. To accommodate this,
server scoped Lua states are stored in an apr
resource list. The
min and max arguments
specify the minimum and maximum number of Lua states to keep in the
pool.
Generally speaking, the thread and server scopes
execute roughly 2-3 times faster than the rest, because they don't have to
spawn new Lua states on every request (especially with the event MPM, as
even keepalive requests will use a new thread for each request). If you are
satisfied that your scripts will not have problems reusing a state, then
the thread or server scopes should be used for
maximum performance. While the thread scope will provide the
fastest responses, the server scope will use less memory, as
states are pooled, allowing f.x. 1000 threads to share only 100 Lua states,
thus using only 10% of the memory required by the thread scope.
