David,
my current idea is to keep everything in 100% transcript with maybe
some shell() calls. What I have right now is:
* An 100% transcript based webserver.
* A lot of CGI libraries and utilities.
* an experimental FastCGI Daemon written in transcript.
That blog post is very interesting and I too follow some ideas
outlined in there. The only thing I am trying to solve is the denial
of service problem during blocking calls. Even with FastCGI we do
have such trouble. None of my web apps running under FastCGI can
contain a single blocking call for even if a smal "wait 10 ticks"
happen inside the app, the whole engine will block.
Thats why I (and others) recommend using plain old CGI for real world
scenarios. Spawning one rev instance per request is not that bad, the
interpreter is small enough and starts very fast.
As for your question on putting RevHTTP behind a good proxy, the
problem again is blocking calls. If the engine is busy figuring out
some lenghty calculation and the master proxy tries to send something
more, then we're pretty much in denial of service.
any clue?
Andre
On Jan 25, 2007, at 11:57 AM, David Bovill wrote:
Along hose lines Andre - why not just put the Rev HTTP servers
behind a
mature http proxy as they do in the Java and Zope world? Here is an
article:
http://www.vmunix.com/mark/blog/archives/2006/01/02/fastcgi-scgi-
and-apache-background-and-future
And a quote from the above:
What Java and Zope app servers do (for the unfamiliar) is run their
own
solid HTTP servers that do intelligent URL parsing/generation for
you to
make sticking them behind a HTTP proxy (like Apache's mod_proxy,
or Squid,
or whatever) at an arbitrary point in the URI a piece of cake.
Typically you
redirect some URL's traffic (a virtual host, subdirectory, etc.)
off to the
dedicated app server the same way a proxy server sits between your
web
browser and the web server. It works just like directing requests
off to a
Handler in Apache, except the request is actually sent off to
another HTTP
server instead of handed off to a module or CGI script. And of
course the
reply comes back as a HTTP object that's sent back to the originator.
There's a bunch of reasons why doing this with HTTP instead of CGI
is a
really nice approach. One is that setting up these app servers
becomes
pretty simple for sysadmins and doing the configs on the upstream
webserver/proxy is IDENTICAL no matter what kind of downstream app
server
you're talking to. That's reduces errors. It's flexible, too,
allowing you
start up an app server instance (which, of course, acts like a web
server)
on a port, run it as whatever system user you want, jail it, zone it,
firewall it, whatever, and then you send HTTP requests to the
thing. You can
go straight to the app server in your web browser to debug stuff.
Since it's
HTTP we already have a full suite of tools that can do intelligent
things
with the protocol. Firewalls, load balancers, proxies, and so on.
There's a
huge market of mature "HTTP brokers" both free and commercial,
including
Apache itself (mod_proxy, which can be hooked into rewrites).
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
