Those of you out there that work with PHP and Oracle might want to check out the new article that Alison Halloway mentions in her blog today - a reprint of a fellow Oracler - Richard Rendell's article, "The Oracle PHP Connection" [pdf].

In this article we take a look the connection methods used for PHP and Oracle database using the PHP OCI8 extension. Specifically we cover non-persistent and persistent connections while offering some suggestions for choosing the right approach. In addition we will cover some upcoming features in the next major release of the Oracle database to significantly improve scalability of PHP applications.

He talks about [pdf] the types of Oracle->PHP connections, what the database name connection strings are (with examples) the environment variables for connections, closing the connections, a look at connection pooling, and an overview of using DRCP (Database Resident Connection Pooling) to accomplish it.

In his latest blog entry, Jeff Moore tries to dispel a rumor about PHP code that's been floating around for years now - that it's considered hard to maintain.

The technocrat, heavily invested in his own technical prowess, faced with successful yet technically inferior code experiences cognitive dissonance. The only thing to do is to belittle the successful, but surely offensive code. "I could write better code than this," he says, or "this code sucks," or "this is unmaintainable."

Unfortunately, what Jeff says about many programmer's first introduction to PHP is right - that they download a popular application to check it out. This code is not always, shall we say, stellar. Jeff also brings up the point that the "PHP doesn't scale" myth goes hand in hand with this. After all, the larger the application, the larger the code, right? And the larger the code, the less maintainable it is, right?

Of course not - there are wonderful large PHP applications that are as easy to jump into and add/modify functionality to and keep up to date as there are small. PHP has one major thing going for it - it's simple nature lets developers keep things simple, and simple is good.

John Coggeshall has linked to the download of the slides from his latest (and very popular) conference talk - Top 30 Scalability Mistakes.

For those of you who are interested, you can download my slide from the tutorial I gave at ApacheCon this year. This is a very popular talk that I've been giving all year -- and this is by far the most extensive version of the talk yet.

The slides cover topics like system scalability, PHP scalability, database scalability, web server scalability, and using these tips to optimize your application.

On his blog today, Chris Shiflett an article mentioned in this previous post from the O'Reilly ONLamp.com site about PHP and scalability.

There's an interesting blog entry on O'Reilly's web site discussing Digg's PHP Scalability and Performance. As part of his research, the author (Brian Fioca, a Java developer) interviewed Owen Byrne, cofounder and Senior Software Engineer at Digg, and built his own PHP application, Jobby.

Chris also points out some of the interesting comments made in the entry, including mentions of Digg's stats and some great comments testifying to the light, powerful nature of PHP.

When someone talks about PHP and drags up the old "but it doesn't scale well" argument, drop them an email with this new article from the O'Reilly ONLamp.com site that might change their minds. In it, they share some information they gathered (spurred on by James Gosling's comments on PHP a bit back) on how one large site, digg.com, has dealt with their huge popularity and scaling their PHP-based system.

They focus mainly on the cost of scalability - whether that be in hardware costs or simply in manhours. He interviews Owen Byrne, Senior Software Engineer for digg.com about some of his decisions on how to handle the explosive growth. They look at what "performance" and "scalability" really are, and some of Byrne's concerns on the matters as it pertains to PHP. They touch briefly on a few topics, including the hardware cost, the database cost, and the actual PHP coding cost of applications.

It turns out that it really is fast and cheap to develop applications in PHP. Most scaling and performance challenges are almost always related to the data layer, and are common across all language platforms. Even as a self-proclaimed PHP evangelist, I was very startled to find out that all of the theories I was subscribing to were true. There is simply no truth to the idea that Java is better than scripting languages at writing scalable web applications. I won't go as far as to say that PHP is better than Java, because it is never that simple. However it just isn't true to say that PHP doesn't scale.

Pass it on...

cyberlot has posted the second part in his "Using scalability to improve your PHP applications MySQL security" series today on his blog.

In this edition, he gives an example of extending PDO to use two seperate database connections.

Here is a quick example I threw together to extend PDO so you can use 2 seperate database connections.

This extends PDO and only connects to the database when the first query is run. This way if you never use the database connection no time is wasted trying to connect.

It's a pretty simple script, and even those that haven't gotten to mess much with PDO can give it a shot. Basically, you just don't call __construct when creating things. You have to create it with another function that's more configurable...