Shay Ben Moshe has a new post to his blog today looking at some of the benefits that using the persistent connections offered in PDO can have on your application.

PDO is an abstraction layer for database connections in PHP, and it became increasingly popular in the past few years. PDO gives us the option to use a persistent connection. If we don't use this option, a new connection is created for each request. If we do use this option, the connection is not closed at the end of the script, and it is then re-used by other script requests.

He shares the setup for his testing (hardware and MySQL configuration) and some of the results from his tests using the Apache ab tool for making web requests against an application. You'll need to download the archived file to see the results, though. It also includes the files he used to test with, comparing regular connections to the persistent ones.

Alex Mills has a interesting post to his blog answering a question he and several of the other WordPress developers at Automatic get about their blogging engine - why it doesn't including a default caching layer.

WordPress does actually have a built-in cache called the object cache. It was introduced way back in 2005 1 and it basically caches database query results. [...] However as soon as the page is done being generated, that object cache is discarded. Initially the object cache cached these little chunks of data to the filesystem so that they could be reused on subsequent pageviews. While great in theory, the concept turned out to be terrible in practice.

They opted out of the persistent object caching because, well, it was slower than some of the preexisting alternatives out there like database caching and caching plugins (with WP Super Cache).

The Internet Super Hero blog has posted some statistics comparing the connections per second that can be made with the newly introduced persistent connection support coming with PHP 5.3 in the mysqli (ext/mysqli) driver.

Persistent Connections have been a mixed bag. They can give you a significant performance boost by caching (pooling) connections although MySQL is already comparatively fast at establishing connections. However,connections are stored "as-is" in the cache. They are not "cleaned up".

The ext/mysqli driver takes care of this and a few other problems surrounding the persistent connections by cleaning up things like rolling back active transactions, unlocking tables, closing prepared statements and closing handlers. The trick is in a call to the C-API function mysql_change_user() (= COM_CHANGE_USER).

Lukas Smith is looking for a little help on a strange problem he's seeing connecting to a SQL Server with persistent connections:

We are connecting to SQL Server via mssql_pconnect(). MaxChilds is set to 256 and we are only establishing one connection per request. So as a result I am expecting a maximum of 256 established connections. A client went into production yesterday and due to a missing index the server ended up being insanely loaded, as the queries started to block each other. The sysadmin checked the state of things via netstat and found that there were close to 500 tcp connections to the SQL Server. What gives?

He checked FreeTDS and the MaxRequestsPerChild settings to ensure that nothing there could have caused the problem, but hasn't found any hints so far. If he can't solve it right away, he also wonders if there's a way to kill idle connections if they're not used in a certain amount of time.

There's already one connect that mentions a similar issue but with Oracle connections, also on RHEL, but no definitive answers so far.

On her blog, Objectively Oriented, Maggie Nelson looks at a topic she was debating for a new application - whether or not to use persistent connections to her database.

There's a connection already waiting for you. Yay, right? Well, with MySQL, connecting is actually really really cheap, and frankly, if you are using persistent connections, you might encounter some issues with Apache going zombie on processes that use a connection, effectively taking that connection out of use. Grrr.

She did some research on the topic but found contradicting evidence for both sides. Eventually, what her choice boiled down to was this possible issue mentioned by Jay Pipes (of MySQL):

If you use Apache, Apache can zombie a PHP process and cause the mysql connection to be held until the mysql server restarts...

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.

The Developer Tutorial website has a new article posted today about the creation of "state-enabled applications" with PHP. Basically, a chunk of functionality to keep user data persistent throughout the whole time they're on the site.

A major drawback is that while browsing from one page to another, the website does not remember the State of the browsing session. This make interactivity almost impossible. In order to increase interactivity, the developer can use the session handling features of PHP to augment the features of HTTP in order to remember the State of the browsing session.

They look at two solutions - using cookies and using sessions. Cookies are simple enough, but when it comes to sessions, there's actually two different roads to follow: with cookies enabled and without. They have to be handled slightly differently, but both essentially work the same way.

Tobias Schlitt has pointed out a new article he's written up that acts as an introduction to the features of the new ORM component of the eZ Components application framework - the PersisteneObject.

For me the coolest feature of PersistentObject is, that the component does not require you're ORM enabled classes to inherit from a certain base to allow your objects to be stored in a database (made persistent).

This new object gives you a "wapper" of sorts to make any of the pre-existing objects in your application persistent. Check out the article for more.

In this new blog post, Stoyan Stefanov shares a method he's found to reuse an existing database connection with the MDB2 library.

This is a follow up to a question posted by Sam in my DB-2-MDB2 post. The question was if you can reuse an exisitng database connection you've already established and not have MDB2 creating a second connection.

He gives two different methods, one for persistent connections and the other for non-persistent ones - including some code.

The MySQL Performance Blog takes a look today at a more PHP-related topic - persistent connections in PHP and whether or not they are the devil (well, okay, so maybe not quest that bad - just a little evil).

The reason behind using persistent connections is of course reducing number of connects which are rather expensive, even though they are much faster with MySQL than with most other databases.

They go on to talk about:

• issues with the number of active connections that could come up
• the use of too many connections at once
• why persistent connections are disabled in the new mysqli extension

Their conclusion? Persistent connections are not evil. In fact, they're very good, when used in the right context and for the right kinds of queries. There's also a small push for an even newer MySQL driver for PHP by the MySQL team - the "mysqlnd" driver.