Re: "Linux Knowledge Base"

["Dana M. Diederich" <dana@realms.org>]

Howdy everyone.  I greet you on Christmas Day!  Attached at the bottom is
a minimal perl script connecting to a data source via DBI and pulling data.

> mod_perl and CGI.pm are for two different things.  mod_perl speeds up
> execution of CGI's on the server
Right...

> by avoiding a fork/recompile each time.
Not quite.  mod_perl keeps a persistent interpreter resident in memory,
inside the web server.  (I'm not sure if it's a different process, or
actually in the httpd space, but it's certainly persistent.)  Speed
savings come primarily because a new interpreter doesn't need to be loaded
at every cgi invocation.  The perl interpreter is rather large.

It does save a fork too.  Since linux uses vfork by default, linux does
indeed have the 'fastest fork in the west'.

mod_perl is a Good Thing, and there's nothing wrong with starting out with
it, but I rarely run into situations where the savings are required,
given a server with plenty of memory.  The perl interpreter is large, but its
frequently called, so it'll cache into memory in any case.

One one of the big linux boxes at work, I've asymetrically run thousands of
cgi calls a second without mod_perl.  With mod_perl, it's about three times
higher.

I guess my point is mod_perl is ok, but let's not let it slow down
development for any reason.  If that happens, we can get to it later.

> CGI.pm is a developer tool to make writing CGI's and forms easier in Perl.  
Righto, CGI.pm is a life saver.

> With that strict of a limit, there won't be any rendered buttons- they'll
> have to be fonts.  Not complaining, just an observation.  One thing to
> consider though, is how much caching we can do.  If we use the same images
> over and over again, we can afford a large over all size.  A good example
> is www.gimp.org wihch is well 100K.
Using fonts can be problematic with older browsers.  (Third generation 
browsers.)

Over-engineering web pages is a trap I've fallen into more often than I like
to admit over the years.  Some of the BEST web sites I've seen out there
have < 50k of graphics, and nothing more than HTML 1 technology.  I guess the
key thing to remember is that it's content that makes the site, not the web
pages.

Here's a minimal perl script that connects to a DBI data sources and grabs
some data:
__________CUT HERE__________
#!/usr/bin/perl -w

use Strict;
use DBI;

my $widget_id;
my $widget_name;
my $widget_type;

my $dbh = DBI->connect('DBI:mysql:netmgt', 'userid', 'password');
my $sql = 'select id,widget_name,widget_type from widgets where widget_maker = 4 order by widget_name';
my $sth = $dbh->prepare($sql);
$sth->execute;
print "<TABLE><TR><TD>Widget ID</TD><TD>Widget Name</TD><TD>Widget Type</TD></TR>\n";
while(($widget_id,$widget_name,$widget_type) = $sth->fetchrow_array) {
	print "<TR><TD>$widget_id</TD><TD>$widget_name</TD><TD>$widget_type</TD></TR>\n";
}
print "</TABLE>\n";
__________CUT HERE__________
<PREACH TARGET="CHOIR">
Of course, the cool thing about DBI (and the thing that ODBC tried and failed 
to do) is that nothing in this program changes except the second field of the 
first argument to DBI->connect if the data source changes, to Postgres for
instance, or even Oracle, SQL Server, Informix, whatever.  Heck, there's even
a DBI interface to flat files if you want the ultimate in 'server' stability!
</PREACH>

Cheers.
-Dana
-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,
Dana M. Diederich        Phone: 1.501.855.7175
SMTP: dana@realms.org    HTTP:  http://realms.org/   ICQ: 16433785
Snail Mail: 19 Leicester Drive, Bella Vista, Ar 72714, USA
`Berkeley invented LSD and Unix, and I don't think that's a coincidence.'