On 2/6/09 8:09 AM, Bertrand Mansion bmans...@mamasam.net wrote:
What do you call slow ? Do you have benchmarks ?
Some round numbers:
No Lua at all: 40k/sec
Our hack version (based on older mod_wombat): 34k/sec
New mod_lua: 20k
Most of this it seems is from the lua states being created for
On Fri, Feb 6, 2009 at 3:09 PM, Brian Akins br...@akins.org wrote:
On 2/6/09 8:09 AM, Bertrand Mansion bmans...@mamasam.net wrote:
What do you call slow ? Do you have benchmarks ?
Some round numbers:
No Lua at all: 40k/sec
Our hack version (based on older mod_wombat): 34k/sec
New mod_lua:
On 2/6/09 12:17 AM, Brian McCallister bri...@skife.org wrote:
* One entry point to obtain VMs
This is the apl_get_lua_state(..) function. It is passed the
information required to either find, or create the needed
lua_State. This is:
- the lifecycle pool to which it is bound
-
On 2/6/09 9:40 AM, Bertrand Mansion bmans...@mamasam.net wrote:
I remember having met a lot
of problems with the old mod_wombat due to persistent states, even
with cache set to never. In the end, I had to restart the server
each time I modified a lua source file. It seems that you suggest to
Hi Brian,
On Fri, Feb 6, 2009 at 1:54 PM, M. Brian Akins br...@akins.org wrote:
We want to be able to get back to stock mod_lua, but it's just too darned
slow right now :( Having some type of per-allocation and long lived
LuaStates helps this allot. All the C stuff is done that way (in
On Feb 6, 2009, at 12:17 AM, Brian McCallister wrote:
* VMs are attached to apr pools.
+1
* Concurrency is up to the client
What are you defining as the client?
We should not expose configuration options which will create
concurrency issues, such as attaching a VM to the server_rec
Paul and I seem to be stepping on each others toes, so I want to
settle on how lua_State (vm) management should work.
My opinion:
* VMs are attached to apr pools.
* A pool may have several VMs attached to it
Each VM has a name, that name is part of the key in the pool
userdata key.
*
