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.

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.
  ]]> Mon, 08 Dec 2008 11:19:37 -0600 http://www.phpdeveloper.org/news/5442 http://www.phpdeveloper.org/news/5442 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.
  ]]> Wed, 24 May 2006 17:49:15 -0500