> Hi
> > > If you want a fair contrast, test PHP vs. Perl when Perl is in
> > > some sort of similar environment. Perl and Apache with mod_perl,
> > > or Perl and IIS with PerlEx, or Perl and FastCGI, or Perl and
> > > VelociGen, or... And don't do something useless like
> "Hello world",
> OK
>
> > > which only tests the startup cost, when you can make a
> more >> > > test
> >using something your website already does [or needs to do].
> I didn't realise there was a startup cost - but I understand
> (compiling,etc)
There is a substantial startup cost with Perl CGI, because each request will
launch a new instance of the Perl interpreter, then the script must be
compiled. The PHP environment, on the other hand, has the interpreter always
resident in memory. This is why PHP is faster than a CGI solution. However,
the reason why it is not a fair comparison, as David mentions above, is
because there are many ways to have the Perl interpreter resident in memory,
such as with Apache's mod_perl module. This eliminates the startup penalty,
and makes Perl as fast (if not faster) than PHP. Many large sites use
mod_perl and it scales very well.
>
> > > You say that "company standards dictates that the database is
> > > Oracle." But how is PHP going to do a decent job of
> interfacing with
> > > Oracle [any version]? Perl/Apache/mod_perl on linux will let you
> > > run DBI and interface with Oracle in an effective manner,
> including
> > > maintaining a database queue which the webserver can toss requests
> > > at. PHP can do this for MySQL with ease, but it is not as good
> > > at doing the same for other databases, and it is far
> worse in terms
> > > of having to change the database after the fact [for upgrades or
> > > changes in company policy or whatever].
> It sounds to me like we must build up a comprehensive bench-marking
> exercise then including database accesses, updates, etc. Thanks for
> this tip. I was shot down in flames when I tried moving them away
> from Oracle, so basically this works for me (in getting Perl in).
>
> > > to the boffins. If you know Perl you can learn PHP
> easily - it > > a
> >lot like a web subset of Perl. On the other hand, if you're up to
> > > the task, then show your boss that someone is pulling the
> wool over
> > > her eyes, and then demonstrate what mod_perl can do for your
> If Php is a subset of Perl, then I suppose it can't do all the things
> Perl can? Our system is a commerical application with tens of
> thousands
> of customers and it is very sophisticated. They really had to use some
> fancy reusable coding in Delphi to get it working right. I wonder if
> Php can handle a big system.
I would say its highly unlikely. PHP was built for serving web pages. That's
it. What if you needed to run an automated scheduled task to do some
database maintenance chore or something similar? You couldn't write it in
PHP. What if someone later decides that the web interface doesn't cut it (or
should be optional) for a particular task, and needs a little client
program? With PHP you'd be dead in the water.
> One argument these guys had was something about having "too many
> CGI scripts in your system" but I can't see how that can be avoided.
> It seems to me they are actually arguing for something small???
That's pure FUD. Anyway, if you use mod_perl for everything, you'd have zero
CGI scripts.
--
Mark Thomas
[EMAIL PROTECTED]
---
You are currently subscribed to perl-win32-users as: [archive@jab.org]
To unsubscribe, forward this message to
[EMAIL PROTECTED]
For non-automated Mailing List support, send email to
[EMAIL PROTECTED]
