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.

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).

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).

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.

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...

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.

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.

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.

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 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