Path: news.cs.au.dk!news.net.uni-c.dk!arclight.uoregon.edu!logbridge.uoregon.edu!fu-berlin.de!cs.tu-berlin.de!uni-duisburg.de!l1-hrz.uni-duisburg.de!sb463ba From: sb463ba@l1-hrz.uni-duisburg.de (Georg Bauhaus) Newsgroups: comp.lang.beta Subject: Re: BETA for CGI Date: 19 Jun 2000 17:49:34 GMT Organization: Gerhard-Mercator-Universitaet - Gesamthochschule Duisburg Lines: 82 Distribution: world Message-ID: <8ilmfe$qv2$1@news-hrz.uni-duisburg.de> References: <20000619141125.4936.qmail@noatun.mjolner.dk> <8ilbgr$8l0j$1@xinwen.cs.au.dk> NNTP-Posting-Host: l1-hrz.uni-duisburg.de X-Newsreader: TIN [version 1.2 PL2] Xref: news.cs.au.dk comp.lang.beta:12443 Erik Corry (corry@mjolner.dk) wrote: : Sascha Kimmel wrote: : > Lars Balker Rasmussen said: : With a perl CGI the perl interpreter would be shared in the same : way, but every time you start the perl script the interpreter has : to compile the script to its own internal format. : The performance tradeoff depends on how large your perl program is, : how many different CGI scripts you have, whether perlmod is an : option and how heavily you use regular expressions, which are : heavily optimised in perl. : > much RAM for this (imagine a high-load-website with 50 calls to your CGI app : > (in BETA) per second - if your file has a size of 1MB this means starting 50 : > of these files as fast as possible, so that the clients don't have to wait : > and "wasting" your RAM with 50MB of code. From experience in a relatively high load setting[+], I would like to submit that running Perl-CGI Scripts on our servers with high load (>50 apache instances, grouped using different configurations, order of a million hits per month) had to be dropped, not enough performance because of startup/compile/interpret. (Lots of dynamically created content, DB-supplied). Then mod_perl was compiled in, blowing up the executables (it looked like Perl cannot be shared across instances of apache). Perl programming then becomes a trickery: Avoid using any global variables, consider *every* warning Perl can give you, in essence stop using Perl as a _scripting_ language. Learn a lot about unix processes and forking, all this in connection with the built in perls, mod_perl-required additional configuration, and the modules' data handling. Touching Perl library modules that were used in the scripts would not be noted in the running servers, thus signal -HUP or -USR1, reload. : >> [The implementation of a PERL::CGI-like] : >> module for BETA is left as an exercise to the interested reader. For quite some CGI scripts CGI.pm turns out to be overkill. While easy to use, much of it can be avoided at the cost of a few hours/minutes of addtional programming. Afaics, CGI.pm is a convenience module, not something to be used where performance counts[*]. Thus, if I may say so, this might reasonably remain a recurring exercise :-). As for REs, we have found (once again, presumably) that they form only small part (the "data laundry" stage) of the algorithmic work in a script that does something. Thus, it seems like in this kind of setting, the myths have to be boiled down somewhat in order to arrive at figures that With apologies for mentioning still another language than BETA for a RE source, there is a free implementation of SPITBOL patterns in the GNU Ada 95 compiler libraries. (no GPL need). How do you intend to have programmers build REs in a BETA source program? Using strings of "+\w\G\d*(?i:#)"-Syntax? Really? :-) I'd prefer a mix with sth like re.alpha->re.digits->re.compile->matcher; where alpha and digits output corresponding RE-patterns (Sorry if I messed the syntax.) Georg Bauhaus [+] This is a place, not a the organization: mentioned in the headers, where almost all pages hold tables of dynamically filled in content or a USENET-like "discussion interface" (shame on us using the WWW for that :-). [*] for an equal result, try time perl -e "use Date::Manip;" (very convenient, 140k RE loaded Perl-library) time perl -e "use Date::Calc;" (convenient, C-library)