Re: Do Rev CGI Suffer Performance HIts?
Richard Gaskin wrote: Dan Shafer wrote: On another thread, jbv (JB) wrote about using Rev as a CGI engine on Linux as a matter of regular course. I'm curious. I've been laying out a design for an INternet-based app and figuring I'd have to use Python (which is OK because I love it but in some ways it may be overkill for this project) because of my understanding that a Rev CGI can't handle even modest volumes of traffic. This is apparently because a separate instance of the CGI is launched for each HTTP request received. True or myth? It's true on all non-Mac servers (Macs can use Apple events), but how is this different from Perl or Python? It's the same, for Perl as CGI and Python as CGI. But both mod_perl and mod_python exist, and are (reputedly, haven't seen any figures or benchmark numbers) much faster than starting a new interpreter each time. I know that in recent years there's an option in Apache to keep Perl resident in memory, but behaviorally it still acts as a separate instance. If there isn't commonly the same sort of option for Python, then my hunch is that the resource demand would be measured by a combination of engine size (load time) and engine efficiency, and may not differ dramatically from the Rev engine. Jacque recalls Scott Raney once noting that when called as a CGI, the "faceless" engine does a lot less work at startup and loads almost instantaneously, even faster than a scriptless standalone. Do I misunderstand something about CGI and/or Python? Anyone have any hard comparison data about relative efficiencies between Rev and Python? Yeah - they're both faster than the other for some things. Tell me which area you're interested in and I'll concoct a benchmark to prove that one is faster than the other; you tell me which one you want to win, and I'll make it win :-) There is always the other option, of running a Rev (or Python, or Perl, ...) server, and serving requests directly from that. This can give significantly better response times and significantly higher transaction rates - but it means the server needs to satisfy all requests - even those that could have been left to basic html. And it means that you have a single instance - so in some cases the programming gets orders of magnitude harder, while in others it might get easier. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.9 - Release Date: 12/05/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Do Rev CGI Suffer Performance HIts?
Dan Shafer wrote: OK, having spent some time in the archives, I think I've answered my own question. It *is* necessary for a Rev CGI script to load separately for each instance/call. That's not terribly efficient but it's like all other CGI methods except for mod_perl and probably some other even more obscure methods. I ran across a couple of references to a comment perhaps made by Scott Raney that load time is pretty instantaneous and therefore shouldn't be a performance problem (though it might clearly become a *resource* problem on the server). So I think I'll experiment with this a bit, using Python and Rev for a couple of simple but heavily used CGI and see what results I get. as well as mod_perl, there is also mod_python - so if transaction rate is important to you, you may want to try that as well as python as CGI. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.9 - Release Date: 12/05/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Do Rev CGI Suffer Performance HIts?
Dan Shafer wrote: On another thread, jbv (JB) wrote about using Rev as a CGI engine on Linux as a matter of regular course. I'm curious. I've been laying out a design for an INternet-based app and figuring I'd have to use Python (which is OK because I love it but in some ways it may be overkill for this project) because of my understanding that a Rev CGI can't handle even modest volumes of traffic. This is apparently because a separate instance of the CGI is launched for each HTTP request received. True or myth? It's true on all non-Mac servers (Macs can use Apple events), but how is this different from Perl or Python? I know that in recent years there's an option in Apache to keep Perl resident in memory, but behaviorally it still acts as a separate instance. If there isn't commonly the same sort of option for Python, then my hunch is that the resource demand would be measured by a combination of engine size (load time) and engine efficiency, and may not differ dramatically from the Rev engine. Jacque recalls Scott Raney once noting that when called as a CGI, the "faceless" engine does a lot less work at startup and loads almost instantaneously, even faster than a scriptless standalone. Do I misunderstand something about CGI and/or Python? Anyone have any hard comparison data about relative efficiencies between Rev and Python? -- Richard Gaskin Fourth World Media Corporation __ Rev tools and more: http://www.fourthworld.com/rev ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Do Rev CGI Suffer Performance HIts?
Dan, Again you should check with Pierre Sahores who has developped a different method based on stacks running & "listening" non stop for requests, and therefore don't need to load for each instance / call and seem to be able to process several hundreds (IIRC) of requests per second... JB > > > It *is* necessary for a Rev CGI script to load separately for each > instance/call. That's not terribly efficient but it's like all other > CGI methods except for mod_perl and probably some other even more > obscure methods. > > I ran across a couple of references to a comment perhaps made by > Scott Raney that load time is pretty instantaneous and therefore > shouldn't be a performance problem (though it might clearly become a > *resource* problem on the server). > > So I think I'll experiment with this a bit, using Python and Rev for > a couple of simple but heavily used CGI and see what results I get. ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Do Rev CGI Suffer Performance HIts?
OK, having spent some time in the archives, I think I've answered my own question. It *is* necessary for a Rev CGI script to load separately for each instance/call. That's not terribly efficient but it's like all other CGI methods except for mod_perl and probably some other even more obscure methods. I ran across a couple of references to a comment perhaps made by Scott Raney that load time is pretty instantaneous and therefore shouldn't be a performance problem (though it might clearly become a *resource* problem on the server). So I think I'll experiment with this a bit, using Python and Rev for a couple of simple but heavily used CGI and see what results I get. ~~ Dan Shafer, Co-Chair RevConWest '05 June 17-18, 2005, Monterey, California http://www.altuit.com/webs/altuit/RevConWest ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Do Rev CGI Suffer Performance HIts?
Dan, > True or myth? Anyone have any experience with moderately high > transaction rates using Rev CGI? It depends on what you mean by "moderately high transaction rate"... As for the few sites I've developped around Rev cgi, the one with the "highest" transaction rate was an event in spring 2003 which lasted 15 days, and got 45,000 visitors for 2,500,000 pages viewed. Actually, the cgi engine was MC 2.4, but I guess the situation can be considerd as similar to using Rev 2.5. What I love about using Rev cgi is the fact that when specific client apps are needed (to manage / update the content of the website for instance), it is easily done with Rev, and furthermore both client app & cgi scripts are written in the same language, and productivity / maintenance-wise this is unvaluable... In the above mentioned website, a couple of ppl were in the middle of the desert with a client app (made with MC) running on a laptop hooked to a cellular phone & satellite connection, and were updating the content of several pages of the site several times a day... Besides, GPS data were received by email every 15 min and a cgi script was used to update complex HTML framesets with maps of the desert and positions of cars... everything ran flawlessly (except when the company in charge of receiving / transmitting GPS data to our server was facing unexpected & unexplained gaps in data streams)... The same ppl with the same laptop & satellite connection were also downloading GPS data from our server via another small client app (also made with MC) that updated & displayed the same maps & positions on the laptop than on the website. But it looks like much higher transaction rates can be achieved : Pierre Sahores has posted several explanations about what he's done around Rev cgi. You should contact him or chack the archives... JB ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Do Rev CGI Suffer Performance HIts?
On another thread, jbv (JB) wrote about using Rev as a CGI engine on Linux as a matter of regular course. I'm curious. I've been laying out a design for an INternet-based app and figuring I'd have to use Python (which is OK because I love it but in some ways it may be overkill for this project) because of my understanding that a Rev CGI can't handle even modest volumes of traffic. This is apparently because a separate instance of the CGI is launched for each HTTP request received. True or myth? Anyone have any experience with moderately high transaction rates using Rev CGI? ~~ Dan Shafer, Co-Chair RevConWest '05 June 17-18, 2005, Monterey, California http://www.altuit.com/webs/altuit/RevConWest ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
