Phoenix.pm: Best PHP reference book?

[Mike Sherwood]

On Mon, May 05, 2003 at 07:15:46AM -0700, Victor Odhner wrote:
> Scott Walters wrote:
> > Not to start a flame-war, but if you know and understand
> > Perl, why would you want to "learn" PHP? Just another resume
> > buzzword, you have to use it, what? Perl is already slighted
> > enough for not being a serious programming language, only
> > suited for rank hacks with no engineering discipline and
> > script kiddies (also with no engineering discipline).
> 
> I'm afraid I don't understand what you're trying to say here.
> Is it that you don't like PHP?  Or you don't like Perl?

PHP is basically a crippled version of Perl with some minor syntax
differences.  This is how I think of it and it's made it easy to
transition from writing web applications in Perl to writing them in PHP.
It's just another tool to do the same types of jobs for some people.

> Perl works.  PHP is just, well, a piece of the Perl/Apache
> thing as far as I'm concerned.  I'm working now in a system
> that has some growing CGI response problems -- the pains of
> growing success -- and working in-process (PHP, ModPerl) may
> be part of the solution.  Not the whole solution, mind you --
> excessive database hits may be the real problem, but first
> they have to break up the 6,000 line monolithic library that
> gets loaded by each CGI call.  Um yeah, do you think?  ;-)

For this, I'd be inclined to try to write some little benchmark applications
before going too far towards one type of solution.  Ie, put some realistic,
if not extreme load on the database and see how it responds.  Converting to
PHP or ModPerl may be of some help no matter what the problem is.  However,
the best case scenario is to asymptotically approach the database performance.
There are a lot of ways to set up a database that don't scale well.  Looking
at this end first is what I'd do.  It sounds like there are a lot of problems
that may warrant completely rewriting the application, and a new language is
a good motivation to do this and take an opportunity to do some redesign.
Loading large libraries every time something is called is likely to impact
performance negatively, but to what degree is important to know.  If it's
taking 2 extra seconds for each execution to load this large library and
30 seconds to get a response to a query, the 2 seconds stops looking so bad.

I have some PHP books, but in practice I found just using php.net like
one would use cpan to find all the information you need on specific
functions and examples works pretty well.  I know at least one of the books
I have is the PHP&Mysql one (O'Reilly, I believe).  It wasn't bad as casual
reading for syntax and rough ideas, but it left me thinking it would be a
poor all-in-one reference.  The examples they gave in there seemed like they
could get someone into the position you're in - a working application with
scalability issues.  Then again, MySQL always leaves a bad taste in my mouth
anyway.
-Mike