On the ServerGrove blog today there's a new post talking about TTL collections in MongoDB - queries with a time-to-live set on the indexes - and includes how to use them in PHP.

MongoDB (v. 2.2+) provides a mechanism to expire data from collections by setting a TTL -time to live- on indexes. This is a great feature if you have data that needs to persist in the database for a specific period of time. The TTL feature allows you to expire data using the MongoDB daemon instead of having to create cron jobs to delete expired data. [...] The MongoDB daemon (mongod) checks regularly for documents in collections with a TTL and removes the expired documents.

Using it from PHP is relatively simple - all that's needed is a configuration parameter on the "ensureIndex" call setting an "expireAfterSeconds" value. There's also a bit included in the post for the Doctrine users out there, showing the docblock comment to use to set the value.

On the Procurios blog today there's a new post talking about a different sort of way to optimize your site's perfomance - fragment caching.

So if web caching is not an option, what is the next best thing? To cache parts of the page, put them together, and serve that. You can use a caching tool for this, like Memcached. There's only one catch: the cached content may need to change when any of the things it depends on changes: data, code, user input, and the like. You can pass an expiration time when you add your content to Memcache. This will cause your cache to live only a certain amount of time and then expire. Nice, but we can do better.

The method he talks about involves expiring the cached data when the dynamic data it comes from has expired rather than setting an expiration time on the data itself. Each time the data its pulled/rendered, the cached data is checked and is updated if the need is there. You're not so much checking for a valid cache as you are forcing an update when needed. There are some side effects mentioned like more database load and increased server load because of the data generation each time.

Code examples are included in the post that use this caching library to get the job done. You can also see how it works in the test file using that library.

Timothy Boronczyk has posted about a new site/service he's created with PHP - Paste Ninja. He details it more in the post:

Paste Ninja is a pastebin application that lets you to share code snippets with others. Instead of flooding an IRC channel or your Instant Messenger conversations with lines of source code, you can paste it online for public viewing.

The world probably doesn't need another pastebin app, either, but there are several features in store that other pastebins don't have.

Features for Paste Ninja include:

• the ability to create threaded pastes,
• set an expiration date for the entry,
• set a password to protect the code,
• see how many times its been viewed
• set the comments on a line-by-line basis
• and - a very cool feature - submitting it via an email account versus just through the site.

From the CentreBlog today, there's an in-depth look at sessions as discovered by resolving a problem of prematurely expiring sessions on their apps.

It started about two weeks ago, with no discernable changes to our configuration that could be responsible. So to understand what was necessary to track down this problem, we have to explore a little bit about how PHP session data storage and expiration works.

They share some of their discoveries, including:

• the session.save_path setting in the php.ini tells the scripts where the sessions go
• garbage collection in PHP checks for sessions older than the session.gc_maxlifetime setting to remove
• but sessions were still expiring too early

They finally started to Google for some answers and discovered that the problem wasn't in the default PHP configuration, the real issue was other software that overrode this php.ini value inside each execution. The result was that a script with the setting of 45 minutes would remove all sessions untouched for more than 45 minutes - regardless if they belonged to other software or not.

From the CentreBlog today, there's an in-depth look at sessions as discovered by resolving a problem of prematurely expiring sessions on their apps.

It started about two weeks ago, with no discernable changes to our configuration that could be responsible. So to understand what was necessary to track down this problem, we have to explore a little bit about how PHP session data storage and expiration works.

They share some of their discoveries, including:

• the session.save_path setting in the php.ini tells the scripts where the sessions go
• garbage collection in PHP checks for sessions older than the session.gc_maxlifetime setting to remove
• but sessions were still expiring too early

They finally started to Google for some answers and discovered that the problem wasn't in the default PHP configuration, the real issue was other software that overrode this php.ini value inside each execution. The result was that a script with the setting of 45 minutes would remove all sessions untouched for more than 45 minutes - regardless if they belonged to other software or not.