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