Thomas F. Burdick <tfb@famine.OCF.Berkeley.EDU> wrote:
+---------------
| venkateshwar_thota@yahoo.com (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

-----
Rob Warnock, PP-ASEL-IA		<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607