[EMAIL PROTECTED] writes:
> You can do the twostage server if you are short on memory, speed is
> important and usage of active content is relatively low. Setup a mod_proxy
> and stripped down apache for port 80 and mod_perl for port 8080 for
> example. Proxy certain urls to the 8080 and you are good. Set low number
> for the mod_perl items, to avoid thrashing. I'd see where Java is weak,
> integration wise like 2 MB per process and not even integrated string
> processing.
I'm sorry I wasn't more clear in my first response. My main point was
not that the common threads I've seen on this mailing list didn't have
good solutions. It was that these things come up alot, and although
there are good solutions, they typically involve something beyond
mod_perl...
I've used dbm files and shared memory before, and I find it easier to
use the built in thread support in java (like I said IMHO of course :)
> So is with FastCGI, reinventing the wheel man is not a good thing.
> Sun people are on this thing to rewrite the world and put a Sun stamp on
> it and make everybody use it. Whahoo.
Never looked at FastCGI, does it allow the request to query the server
while it is running, or is it more like a call to an external server
than get a response? Also, if there are multiple processes running I
don't see how that is any better than mod_perl with a proxy for static
pages?
I would also agree that for things that require hooks into the apache
api, mod_perl can do things that just can't be done with the other
systems. I was simply playing devil's advocate in pointing out that
common themes on this list are non-problems with some other solutions,
and if we're talking advocacy, these issues might come up...
--
[EMAIL PROTECTED]
