On 18 Nov 2006, at 20:19, Dan Shafer wrote:
However, the inability to thread in Rev effectively makes the use
of Rev for
CGI applications pretty limited as a practical matter. Each
execution of the
CGI is effectively blocking in nature. (I'm over-simplifying a bit
here, I
know, but I think this is the primary concern in broad terms.) Each
invocation of the CGI waits for previous invocations to terminate.
In a
low-usage environment, the wait is acceptable and depending on what
the CGI
is actually doing, it can be unnoticeble. But to use a CGI in a
production
server environment where the amount of load is unpredictable or
known to be
large, Rev is a non-starter.
Dan, I don't think this is correct.
Each call to a Rev CGI on a server will start a new instance of the
Rev engine. Many instances can be running at the same time, and
whichever completes first will return first.
I just tested this with two CGI scripts to make sure. One CGI was
timed to take 5 seconds to complete. The second was timed to take 1
second. I called the long one first, and then the short one. The
short one returned first.
To test this from Rev on the client side is a bit tricky. You need to
run two instances of Rev, one for each CGI. This is because if you
use Rev's load url command to two urls from the same server, the
second load request won't be issued from the client until the first
has completed. Is it possible that the client behavior was giving you
a misleading picture of the server behavior?
Cheers
Dave
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
