On Thu, Nov 5, 2009 at 6:23 PM, Alexander Gladysh <[email protected]>wrote:
> Hi, list!
>
>
Hello again! :-)
> I'm trying WSAPI (in the nginx+spawn_fcgi+wsapi.fcgi flavor on Ubuntu
> Linux) to do some quick prototyping, and have stumbled upon some
> inconveniences.
>
> It is quite possible that it's just I'm doing something wrong. If it
> is so, please point me in the right direction.
>
> 1. WSAPI does not react to changes in files unless restarted. I want
> some kind of reload command.
>
>
Touch your application's script and the launcher will reload it. There is
also a "reload" parameter in wsapi.fcgi but it is broken right now (fixed in
github) unless you disable collection of stale states (set "period" to nil).
> 2. If I run io.popen() and do not close the file explicitly, I have a
> zombie process hanging around (my wild guess is that it happens
> because GC does not kick in, as my script does not create enough
> garbage).
>
>
Not really a WSAPI issue, but I can force closing of Lua states when I
discard stale ones, instead of letting the GC close them, and this will
trigger __gc metamethods on these states. My bad.
> 3. I can't supply a callback to WSAPI without wrapping it in a Lua
> module. I'd like to avoid this.
>
>
---- hello.lua
local function hello(wsapi_env)
return 200, { ["Content-type"] = "text/html" },
coroutine.wrap(function ()
coroutine.yield("<html><body>Hello!</body></html>") end)
end
return hello
----
No need for a module. :-)
> 4. WSAPI pollutes global environment (with main_func and main_coro
> symbols). I'd like to avoid adding exceptions to my pet strict module.
>
>
It is a bit of a hack, but I can stuff these inside the "package" table. I
think a better solution will need changes to rings; right now the only way
to reference something in the child state is if that something is global.
5. WSAPI handles duplicate request keys by putting all their values
> into a table. I need to get more PHP-like behavior, when next value
> for the duplicate key would override previous one. I had to copy and
> change the request module to get this behavior. I do want a
> configuration option.
>
>
Ok, this can be an option to wsapi.request.new:
req = wsapi.request.new(wsapi_env, { overwrite = true })
> None of these issues are critical (I'm planning to write my own
> specialized Lua-FCGI binding for the production anyway), but I wanted
> to share them just in case. :-)
>
>
Well, thanks for the feedback. If you are worried about overhead of
wsapi.ringer, you can make an fcgi launcher specialized for a single app:
--- post.fcgi
#!/tmp/aio/bin/lua
require "wsapi.fastcgi"
require "post"
wsapi.fastcgi.run(post)
---
Use this with spawn-fcgi instead of wsapi.fcgi, configure nginx to pass
requests to it, and be happy. Goes from ~1400 req/s to ~1900 req/s on my
machine.
I am thinking of adding an option for wsapi.fcgi in WSAPI 1.3 that will
makes applications persistent but not isolated (all applications in the same
FastCGI process share the same Lua state). This should add minimal overhead
compared to the whole isolation thing.
> Alexander.
>
>
--
Fabio Mascarenhas
_______________________________________________
Kepler-Project mailing list
[email protected]
http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project
http://www.keplerproject.org/
