Thomas F. Burdick <tfb@famine.OCF.Berkeley.EDU> wrote:
| firstname.lastname@example.org (Venkat) writes:
| > Every time I execute, I have to load lisp and kill it. It is taking
| > quite some time in doing so. Is there any way to start lisp command
| > interface in background (once when the first request from html comes)
| > and continue to execute to the remaining http requests(that involve
| > lisp commands) by sending some sort of commands.
| Yes, this is a perfectly viable option. I use a small Perl script
| that does this -- it checks to see if the Lisp process is running, if
| not, its forks off a detatched screen session that starts up the Lisp
| process -- then it sends its stdin to the Lisp process and cats the
| Lisp process's response to its stdout. I use a PID log file to tell
| if the Lisp is running, and communicate over a UNIX socket.
I do a similar thing, with a tiny C-coded program that (almost) mimics
the "mod_lisp" protocol. (That is, it passes all the CGI environment
variables before doing the stdin/stdout "over the shoulder" passing.)
| It's not optimal, but it is a workable strategy to integrate a Lisp
| service into a more normal Unix/CGI setup.
I agree. On a 1.4 GHz Athlon, I can get 70-85 web requests/second
through Apache, the C-code CGI trampoline, and into/out_of the Lisp
server for small interpreted pages, and ~100 requests/second for
small compiled pages. This is plenty fast for the apps that I'm
interested in (which have actual hits rates much less than one/sec).
Later, if still more performance is needed, the CGI trampoline could be
replaced with "mod_lisp", with (almost) no changes in the Lisp server.
Rob Warnock, PP-ASEL-IA <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607