[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: FastCGI daemon
- From: Fabio Mascarenhas <mascarenhas@...>
- Date: Fri, 23 Oct 2009 16:24:19 -0200
On Fri, Oct 23, 2009 at 3:33 PM, Stefan <stefan@chehalispost.com> wrote:
> Jacob Jay wrote:
>> FastCGI is definitely the way to go, but if you haven't, do check out
>> wsapi-fcgi which is part of Kepler (http://keplerproject.org/). I use this
>> with spawn-fcgi and lighttpd/nginx. An additional FCGI-Lua interface may be
>> unnecessary unless you want it to do something notably different to that of
>> the Kepler WSAPI one.
>
> I was under the impression that wsapi-fcgi did NOT persist the scripts
> between invocations, unless you run each script as it's own fastcgi server.
> Running a couple dozen (at least) extra processes that MUST stay up at all
> times doesn't appeal to sysadmin in me.
>
The generic wsapi.fcgi launcher does persist scripts (and each script
is isolated in its own Lua state), but each wsapi.fcgi process can
only serve a single request at a time, so you need to configure your
web server to keep multiple wsapi.fcgi workers to service concurrent
requests. wsapi.fcgi also reloads the script in a fresh Lua state if
the underlying file has been modified.
A caveat: wsapi.fcgi's persistence is useless for things like keeping
session data in memory, unless your web server has FCGI process
affinity. But it is enough to avoid reloading the script and the
libraries it uses for each request, and keeping database connections
and other long-lived resources open.
--
Fabio Mascarenhas