Slashdot Mirror
Advanced PHP Programming
Many of the previous generation of PHP books were fattened with lots of filler: how PHP imports form-submitted variables into its namespace, definitions and examples of valid XML documents, one-line summaries of every PHP function, even an HTML reference. It's like going to Gallagher's Steak House and filling up on free bread. Ladies and gentlemen, may I submit the Atkins-Friendly PHP book. This is not a book about syntax or data structures. This is a book on how to use PHP in enterprise environments. During my first read, I realized around page 126 that I had already learned as much as I had expected to learn and I was just getting started!
The book is very well written, with a friendly tone that is neither pedantic nor partisan. A knowledge of PHP before version 5 is assumed, and the situations tackled are very much from the real world. The focus goes beyond getting what you want to appear in the browser, too; scaling problems of very large web sites, managing a code base with multiple developers, and building your own extensions to PHP are all discussed.
The author draws most examples from a Unix + Apache + PHP environment, and MySQL is the primary database used. The examples are all in PHP5, but many ideas can still be implemented in PHP4. In other words, you can still learn a lot even if you're committed to PHP4 for the near future.
Part I of the book is called Implementation and Development Methodologies (some of these part and chapter names could be a little less clunky, even if they are correct), and the first chapter is about coding style. After that comes a thorough discussion of the new features of PHP5. These are language aspects that are commonplace in other object-oriented languages (e.g., java and python), but which I admittedly knew little about:
- encapsulation: the ability to keep object attributes and methods private or protected;
- static attributes and methods to make class functions or singletons;
- user-definable constructor, destructor, accessor, mutator, and copier functions;
- interfaces, which are like abstract classes. A class can implement one or more of these as well as extend a concrete class;
- exceptions, which allow propagation of errors and warnings back up through the function stack.
Other PHP programming concepts are discussed in this part, such as templating, using the command-line interface, and unit testing. The chapter on Managing the Development Environment includes some CVS basics as well as how to organize and keep separate your development and production environments without breaking what works. Another topic discussed is when to use PEAR classes and when to roll your own.
Part II, Caching, is where the book gets hard-core. Once your application works, how do you optimize its performance and scale it so you can have hundreds of thousands of users?
- You can use static variables to reduce recalculations, and compile your regexps.
- You can cache data on the PHP level in flat files, DBM files, shared memory, or even in user cookies.
- There are also solutions outside of the PHP userspace. The ordinary PHP process takes the text which constitutes the programmer's code and compiles into a assembly-style intermediate code. Then the intermediate code is executed. If a script is executed several times without change, the same intermediate code is created, executed, and thrown away several times. A compiler cache saves this intermediate code and reuses it. The author has developed a free, open-source compiler cache.
- There are also code optimizers, which eliminate dead code and overly-verbose constants.
- Reverse proxies also work in web sites to reduce network latency. Latency occurs when a server is stuck waiting for a request to be completed before it can execute. A reverse proxy server only collects requests, then hands them off on a high-speed network to the actual server.
- This can be made even better with content caching. The proxy can determine if the request requires handling by the PHP webserver at all. If a stale, cached copy suffices, it is served instead.
- Content compression sends your data over the internet compressed. The client's browser is in charge of decompression.
Part III, Distributed Applications, is of big importance to the developer of medium-sized sites. The author discusses the familiar topics of database interaction (including how to troubleshoot your slow queries), authentication, and session handling. Then a chapter on clustering: how to arrange multiple, redundant servers to create a robust, fail-safe system.
The final chapter in this part covers another hot topic: Web Services. Say you want to edit your weblog entries on a real text editor rather than through a web form. If you have RPC (Remote Procedure Calls) set up on your web server, you need only write a script which manufactures a request to a web service and and ships it out. What's the sales rank on Amazon of the book you just wrote? What's the weather like in Medford, Massachusetts today? These are all jobs for web services. XML-RPC and SOAP are approaching the standards state of usage, so using one of these means you don't have to develop your own RPC client or server library. SOAP is even richer than XML-RPC: it's an all-purpose messaging protocol which is in use by many of the big players in web services (e.g., Amazon, Google).
In Part IV, Performance, the author returns to the optimization question. How can PHP scripts themselves be made to run faster? There are several techniques:
- Use the apache benchmarker or other load-generating programs to determine which requests take the most time.
- Use a PHP profiler such as the one the author has written to examine your script line-by-line and determine which function calls are most expensive.
- Use a synthetic benchmarker (such as the one included in PEAR) to analyze small bits of code and discover how efficiently they do their task. Which is faster: interpolation of variables or string concatenation (the latter, at least before PHP 4.3)? If you don't have a library compiled into PHP, can you implement all the functions in userspace efficiently (not really)?
Part V, Extensibility, is for people who want to adapt PHP on the language level for their needs. This part requires a knowledge of C and a strong grip on your hat! After a discussion of PHP and Zend Engine (the virtual machine on which compiled PHP runs) internals, the author shows how to make both simple and complex extensions. You can add new functions to PHP, add a suite of library wrappers, add and manipulate classes and objects, all using pre-defined macros. In the last chapter, you can extend Zend itself to (say) implement all errors as exceptions, create a PHP Shell, an opcode-dumper, or modify the author's compiler cache or profiler.
I very much enjoyed the book. I have chosen to take the plunge into PHP5 for a new web project, partly because this book convinced me it's worth it. I can't imagine I'm going to use everything I've learned from the book, but I'm glad to know how problems like these are solved.
There are a few typos and misspellings, but that's to be expected in such a large book with limited turnaround time. Definitely recommended.
Matthew Leingang is a Preceptor in Mathematics at Harvard University. He continues to try to integrate web development into his day job. You can purchase Advanced PHP Programming: A practical guide to developing large-scale Web sites and applications to PHP5 from bn.com. Slashdot welcomes readers' book reviews. To see your own review here, carefully read the book review guidelines, then visit the submission page.
Part V, Extensibility, is for people who want to adapt PHP on the language level for their needs
This is an often-overlooked advantage in PHP: the ability to use php-embed to run embedded PHP within another application. For example, our company has created an HL7 HIPAA-accelerator in C/C++; we chose PHP as the embedded language in our product--by which users can create custom data transformations.
The reason? PHP is easy to use, loosely-typed (which is an advantage in our project), fast, and of course, free. It was a great decision.
Sigs cause cancer.
I've been told by the Apache crowd that the Prefork MPM obviates any concerns of thread safety in libraries.
I've been using 2.x for about a year. Zero problems. Performs great.
John Kerry is a Joke!
The early versions of Apache 2 really scared a lot of people away. It scared me away. Switched to Apache 1 and things started working again. Now that doesn't excuse my poor skill in the sysadmin realm, but I would doubt I am the only one who had headaches with 2.
-Phantom
Um, all you need to know about using the CLI is on this page:
http://us4.php.net/features.commandline
As for php-gtk, there are much better alternatives. And I don't exactly have much faith in something that's developed and supported by only one developer (the cantankerous Andrei Zmievski no less).
On small tables, MySQL will generally win. However, when you get to very large (100+MB) tables, PostgreSQL kicks the crap out of MySQL. Multiple Select/Inserts as a second will favor PostgreSQL too. Finally, PostgreSQL can handle higher single-server loads.
- PHP developers are not opposed to Apache 2.x.
8 &c2coff=1&safe=off&selm=caonem%24rg7%241%40FreeBSD .csie.NCTU.edu.tw
At least one (Rasmus) is:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-
John Kerry is a Joke!
LOL, everybody we know says the opposite. PostgreSQL definitely wins in the ease-of-use category. Sure there's more to learn, since real RDMS's like PG, Firebird, MSSQL, DB2, Oracle have a lot more features than mysql. MySQL has terribly inconsistant and incompatible SQL, lousy docs, lousy interfaces, worse benchmarks. You're just trolling and obviously don't know what you're talking about (and/or are on mysql-ab's payroll).
mySQL is very similar to other SQL dialects.
Um, no. Not even close. Check out all mysql's gotcha's and deviations from SQL standards:
http://sql-info.de/mysql/gotchas.html
I used to think that, until I realized that my programs were twice as complicated as they needed to be due to MySQL's lack of typical relational database functionality. Triggers, views, sub-selects, user-defined functions, transactions, templates... the list of PostgreSQL advantages (feature-wise) over MySQL is long.
MySQL is now trying to catch up to PostgreSQL in the feature category, but is still not even close. That's not to say that MySQL is worthless -- quite the contrary: if you want an indexed file system, MySQL is the way to go. On the other hand, if you want a good, open-source relational database, PostgreSQL is a champ.
Ease of use pushed us away even before we looked at benchmarks, which are all triumphantly in MySQL's favor.
PostgreSQL is a bit harder to initially set up, when compared to MySQL. On the other hand, it isn't rocket science; it is still pretty simple.
In terms of benchmarks, you might want to notice that MySQL is hardly "triumpantly" winning normal benchmarks. Take a typical MySQL table (MyISAM) and try doing lots of concurrent reads and writes. You'll find that MySQL's habit of locking the entire table on writes really is a downer when it comes to performance.
Another thing to note is that MySQL has placed their libraries under the GPL, making them somewhat incompatible with the PHP license. This has caused a bit of a rift in the PHP community, with the result being that MySQL will probably be less supported by the PHP developers while PostgreSQL increases in support.
You ought to be using PEAR's DB class anyway, which abstracts away most of the differences in dialect.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
I'm about 3 months into a ~5-6 month project in PHP. I had never done anything nearly as complicated as I am now, but I have done a lot of PHP programming. Mainly things that took 2 weeks or less.
:)
I bought this book near the beginning of my current adventure and I learned a lot from it. It's not the typical PHP book that just mirrors the php doc web site. There's a lot of great information in there. I'm still on PHP4 but that doesnt matter, the concepts still apply.
Thumbs up!
Joseph?
The major performance advantage MySQL claims over PostgreSQL in real world use is small queries executed in a primarily read-only environment. MySQL also performs deletes and updates very fast, in a single-user environment.
Locking issues cause MySQL to slow down greatly when the database is shared between readers and writers. In fact, any significant amount of concurrent write traffic has, IME, always caused MySQL to deadlock.
My own testing showed that MySQL, on a dual P4-2.4 with PHP could deliver about 630 pages/second with 1 very simple query per page. PostgreSQL delivered 480 pages/second with the same page. This is MySQL's optimum environment and it only beat PostgreSQL by 31%. Certainly something to consider, but hardly earth shattering.
Since PostgreSQL is so much more capable in every other way, it wasn't hard to decide to move everything to PostgreSQL.
I am a sysadmin by profession, working at a mid-sized ISP in Toronto. I chose to be a sysadmin because I don't really enjoy programming -- but the nature of the job dictates that I code to improve efficiency or functionality. Recently I had to work on an in-house web application, and I chose to do it in PHP, but quickly found that the relatively small webapps I've worked on in the past were not much preparation, so I bought this book..
To borrow a phrase, "in a nutshell", this book is excellent! Some of it is beyond my skills at the moment, but I appreciate every bit. The author covers OO in a way that I understood, and presented real-world solutions that helped me understand. But, IMO, the best part isn't the PHP, it's the operational theory -- the real problems that sysadmins and web programmers face with large websites, caching, load-balancing, scalability. This made the book worth the $80CND I paid for it.
I highly recommend it!
-- Steve.
> if you want a good, open-source
> relational database, PostgreSQL is a champ.
Right on. Good utilities are available for it, too!
The Army reading list
I ran across a used copy of this book in The Strand and have to say it has taken its place next to The Cookbook on the shelf of Truly Useful Books. All the "advanced" php books I had found before this one either had a three or four page spread on objects and classes or (in the case of one awful Wrox book) scads of code with little useful description of the considerations that went into its architecture. If you're coming to php from a non-coding background, you'll find that most books seem to stop just before the discussion gets truly interesting (and useful). No, I don't already know how to make use of inheritance, and telling me that it involves extending a class without describing why I would want to do that and how to design classes so it can be done intelligently and powerfully is pretty useless.
This book deals with those advanced topics in substantial depth. Want to know what strategies should be considered in deciding how far to abstract database classes? Want an in depth discussion of preformance caching? Care to contemplate the values of various distributed architectures? Interested in Zend engine internals? From coding style clear through application benchmarking, this book covers it, and it covers it thoroughly and engagingly.
grammar-lesson free since 1999. (rescinded - 2005)
you are a ridiculous karma-whoring troll... this is not information, this is what Rasmus has been saying for a while because not all php extensions are thread safe yet. And Rasmus isn't even opposed to apache 2, he's opposed to people encountering an error with those non-thread safe php extensions. After all, Rasmus IS a core apache http server developer as well.
Certainly, noone is opposed to Apache 2.x. It is a very good idea to make PHP work flawlessly with Apache 2, and once some certain technical problems gets corrected everything will be nice.
PHP is not stable with Apache 2. Rasmus Lerdorf's explanation is widely known, and is part of PHP's FAQ now. Basically, many extensions that PHP rely upon don't work well in threaded environments, and it's quite tricky to know exactly which ones and how to fix them (either on the library level or the PHP level).
Apache 2 was built to handle high volume sites differently, which happens to provide a huge performance boost on Win32 systems.
All in all, your message is kind of disappointing for someone who sounds like he knows what he's talking about.
I bought this book a couple of weeks ago. It's very good. I like the way it covers the general topic of "how to write applications well" as opposed to focusing purely on writing in PHP.
My only criticisms of the book are: (1) It would be nice to see more OO patterns stuff in there (particularly database access patterns), (2) There are a couple of mistakes in the code that got me puzzled for a while. On the whole though, an excellent read.