>>>>> "Micah" == Micah Yoder <yodermk@home.com> writes:
Micah> I then wrote a daemon in C to do the work and store the results
Micah> in RAM. The PHP script connected to the daemon via a socket,
Micah> and passed a request ID and the numbers of the records it
Micah> wanted. Sure, it was convoluted, but I actually got the speed
Micah> up to where I was fairly happy with it.
Micah> If there's a better solution than that, I'm not aware of it.
What you need is a "middleware" (heh) solution... I've done a number
of magazine columns using a Perl-based mini-web-server (search google
for "site:stonehenge.com HTTP::Daemon"). You could set up your
frontware begin-search CGI script to fire off a daemon, and tell it to
do the hard work, using a session ID to keep track of subsequent hits,
and let the front CGI request proxy through using HTTP to talk to the
daemon (very easy). Or, you could redirect the client to the
mini-daemon directly. I've done the latter a couple of times, and
it's pretty practical up to light-commercial-volume hits.
And before you scream "Perl is slow", I have a working Perl webserver
based on HTTP::Daemon that pre-forks just like Apache (taking current
load into consideration), handles streaming proxy connections
(including SSL proxy) and local file delivery, and benchmarks at
*half* the speed of Apache in both proxy and local file mode. That's
much better than I initially expected, and completely satisfactory for
most applications. And it's only 300 lines of code. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!