In his latest post to his site Alejandro Celaya shares some suggestions about how to make a good, safe persistent login feature for your application. This is usually referred to as the "remember me" handling and is widely used to help improve the overall user experience.

I'm sure you are familiar with those "remember me" checkboxes in login forms. They are a common way to allow a user to keep his/her session in a web application for an extended period of time when he is in a trusted computer.

One could think that it is a small and easy-to-implement feature, but it has indeed a lot of considerations. [...] In this article I’m not going to show you how to implement a persistent login in one or another programming language, but what are the good practices that should be followed when you implement it in the way you want.

He starts off with some thoughts about the wrong way to handle the persistent login (like just making a long-life cookie) and what some of the consequences could be. Instead he suggests using a cookie (with a random generated token) that's long running, maybe 2 weeks. The difference here is that this token is then refreshed once the token is validated and reset. This reduces the risk of an older token being used on another source too. He also shares some other security concerns to think about in this setup including the use of one-time tokens, potential multiple persistent sessions and when it might be good to re-prompt for the password.

Mfana Ronald Conco has posted the second part of his RabbitMQ and PHP series to his blog today. This time he looks at durable queues and persistent messages

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 this recent post to his blog Johannes Schlüter he talks about a way that he's come up with to test functionality that uses persistent connections (and an module he created to help).

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.

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.

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.