Where Rev could be going...

jbv jbv.silences at club-internet.fr
Sat Nov 18 16:46:36 CST 2006



Dan,

>
> 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.

as I already mentioned on this very list, I have developped several websites around
Rev cgi, and here are a couple of notes based on my experience :

- most of the time the "wait" is unnoticeble, mostly due to the fact that Rev is
incredibly fast (I have little experience in PHP, but PHP always seems awfully
slow compared to Rev - I have some 6000 lines-long scripts that I  can't imagine
coding in PHP : for instance, scripts that build 10 pages PDf files in about 1 sec to 1.5
sec)

- load has to be really large to cause any noticeble slowness in server response...
another example : I once built a site that had 60,000 visitors in 10 days, browsing
more than 1 million pages (most of them built dynamically by Rev cgi scripts) and
no-one noticed any delay in server response. And that was back in 2002, actually using
MC cgi on a shared server quite slower than today's machines...
the only time when things went noticebly slower was when one of these websites was
launched, and that promotion was done through a newsletter mailed simultaneously to
thousands of ppl, a large part of them logging to the site roughly at the same time...

Best,
JB




More information about the use-livecode mailing list