|
|
sybperl-l Archive
Up Prev Next
From: Doug Fairclough <kensey at clearstation dot com>
Subject: Re: DBlib vs CTlib, please give me a clue!
Date: Oct 10 1997 9:10PM
for what its worth, a friend of mine tried using fast cgi and
had problems with it. he then switched to mod_perl. i think
there are far more people using mod_perl, so that it probably
your best bet as you will get the most help and support from
the community at large, and it will be more stable since it
has a larger base of users.
btw, has anyone out there compiled C code that use DBLIB
or CTLIB directly (without using perl at all) into apache ?
i'm wondering if there is anything in the code making the
database calls that would have to change if you use this
environment/setup.
TIA
doug
On Fri, 10 Oct 1997, Harry Bochner wrote:
> Michael Peppler wrote:
> > Now your best bet to improve performance for CGI scripts is to use
> > the Apache server with mod_perl, as this allows you to a) run CGI
> > scripts without the overhead of a fork()/exec() and b) have
> > persistent database connections,
>
> I certainly agree that for short, simple queries, your bottleneck
> is likely to be the overhead of fork(), exec(), and loading all
> your perl code.
>
> But I'm wondering if anyone has done comparisons between mod_perl
> and FASTCGI. So far I haven't tried either one. On this mailing list
> I've heard mod_perl mentioned much more than FastCgi, but when I
> looked into FastCgi, it seemed like a more flexible and general
> technology. If any one has tried both, I'd be interested in hearing
> about their experiences.
>
> One specific concern I have is handling development. During
> development you _want_ to reload the perl code every time, because
> you're constantly changing it. My impression is that with mod_perl,
> once your code has been read by the server, the only straightforward
> way to load a new version is to restart httpd, and that doesn't
> sound like something I want to do every five minutes. Am I wrong
> about this? It looked like FastCgi might provide other options, though
> you might have to work at it to implement them.
>
> Anyone have experience they'd like to share?
>
> Thanks!
>
> --
> Harry
>
|
