You now have a queuing system that works and generates pdfs which are sent to users as per RabbitMQ and PHP Part 1 of this article. A week later after launching the queuing system you get one or two queries from users who claim to have made a request to get the pdf report but it never arrived. Okay, what could have happened ? well you go through the application log files and as suspected - An Exception was thrown by one your classes as the consumer was trying to create the pdf and that is why it was never sent. Now this compromises the queuing system Totally, But wait there is a way to help prevent such.

He shows how to make your queues "durable", meaning they'll survive a broker restart and they require a response from the consumer before being removed. He shows how (via the php-ampq functionality) to add the "AMPQ_DURABLE" flag to the queue definition. He also includes some code showing how to send back the acknowledgement so the entry can be removed from the queue. He also includes an update to the code that calls "publish" to make the messages persistent too.

In a few rare cases this is not what people like, for that PHP introduced "persistent connections" of different kinds. Testing those is a bit annoying as you have to configure a webserver and ensure to hit the same instance over the course of a test and then use a load generator, probably one which can detect a failure. Additionally by having a webserver in the game there is more code being executed, which might mean an additional source for trouble while debugging. An alternative might be using FastCGI, while that adds it's own issues for such a test. To solve this for myself I, some time ago, wrote a PHP SAPI module called pconn and pushed it to github.

The extension provides a way to emulate requests by executing a script multiple times automatically, making it easier to test things that require checking against multiple things simultaneously. While the built-in webserver (PHP 5.4) can be used to test some of these things too, Johannes' extension can also be compiled to help with testing of threading in applications as well.

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.