Brian Moon has announced the release of the latest version of his memproxy tool that uses memcache to create a "server" to save the proxy information.

I put server in quotes because it is really just a PHP script that handles the caching and talking to the application servers. Apache and other HTTP servers already do a good job talking HTTP to a vast myriad of clients. I did not see any reason to reinvent the wheel.

Features of this new version include a TTL for the cached data, minimal dependencies for the application to use and a small code base consisting of two files. It also handles HTTP 1.1 requests, is transparent and applows pages to dynamically be specifically added and removed from the cache.

You can download this latest version from the project's page on the Google Code website.

Inspired by the nice web interface that the Alternative PHP Cache provides (apc), Harun Yayli decided to hack together his own version for the memcache caching software.

For a long time I was looking for a nice web interface like the apc.php (comes with the apc's source) that displays whole nine yards of stats. [...] Anyways, I decided to rip write my own. Totally based on the original apc.php (I even recycled some functions) and apart from completeness, here is a memcache.php that you can get stats and dump from multiple memcache servers.

Here's the output of his script and he's made the source for it available for download as well.

Hasin Hayder has proposed an interesting replacement for the usual caching mechanism - using the Facebook data storage API to cache copies of pages/data/etc.

Why not! All you need is a fast-n-furious caching storage for your Facebook application which stores values against a key, same like a hash table. Facebook data storage API does the same for you. using the batch API in Facebook rest client you can seriously think it as an alternative of memcache.

He shows the simple process for making the object (manually in a preexisting application), inserting data into the object through the API they provide and how to pull that data back out.

Based off of a previous article from Mike Willbanks, Stuart Herbert has posted some of his own thoughts on tuning and tweaking your applications for the best performance you can get out of them.

There's some good advice in there, and I thought it'd be a good idea to quickly add a bit more detail about the separate approaches that Mike raises.

He goes over the APC caching, memcache, the "gzip trick", the "Not Modified" header and optimized SQL statements.

He also mentions one thing that Mike didn't mention - a split between static files (no PHP needed) and their dynamic cousins. Having a more pure Apache (no PHP installed) can help give a minute jump in speed that, depending on the size of the site, could really add up from a user's perspective.

Brian Deshong has this new post on his blog today with an alternative method for doing the old standby "who's online" for your website.

Whenever you Google around for things like "Who's Online php", you'll find that a lot of the solutions are centered around using a database. However, is this really necessary? [...] One goal here: get Who's Online functionality off of the database. We'll explore a possible solution with Memcached that I've personally implemented, and thus far, it's been working great.

His alternative, using the memcache functionality that can be enabled in PHP, stores a "user ID" (either a real user ID or just some unique identifier) and their last activity time. This information is stored in a local file that can be queued each time the page it loaded. The other piece is a backend script that goes through this same file and clears out the old values. Depending on the size of the file/traffic of the site, this process could even be integrated into the same script that writes it.

Richard Thomas has shared some suggestions on improving the performance and use of PHP's built-in sessions in your site:

If your developing a new website and want to ensure its scalable sessions can be a sticking point. [...] There are a couple problems you may run into with this approach and most database driven examples you may use to base your session code off.

These problems can pretty much be summarized into a single sentence: Every single page load your database is going to be hit at least 2 times, first to read the session data and then session to rewrite all that data.

He includes three suggestions:

• Hash your data when pulled from the DB, if your data hasn't changed don't bother updating
• Figure out what your margin of error is for how long a session has been inactive (don't update if you don't need to)
• Use memcache in conjunction with your database, Check memcache first if its there, if it is use memcache, if its not pull from DB and shove into memcache when you DO update your data update memcache at the same time.

On the HowTo Forge website today, there's a new tutorial with a step-by-step process on installing the PHP-MemCache module onto a system running the CentOS 5.0 operating system.

"MemCached" is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load. In this howto I explain how you can very easily install it and make it available in PHP.

The process only involves five or six main steps (installation, testing, etc not included) finishing with the loading of the memcache.so file into the php.ini for the system to enable it.

From Irakli Nadareishvili's blog today, there's a new post that shows exactly how to get the PECL memcache client up and working with a default XAMPP installation in PHP4.

XAMPP is an absolutely wonderful, packaged, self-contained distribution of apache, mysql, php and tons of hard-to-install php extensions. [...] However, even with a long list of packaged extensions, obviously there may be a need to install an additional one. PECL Memcache client of memcached distributed cache server, is a very probable candidate for high-load systems.

Unfortunately, he notes, the default installation of XAMPP has a broken version of PECL installed and doesn't quite work like it should when new packages are installed. Thankfully, though, he found a workaround for the problem in the form of fourteen (well, really thirteen) easy steps involving things as simple as copying files, running a "make", and changing configuration settings to get things up and working.

He also includes a common error he had to figure out when making his install too - an issue where the installation might not be able to find the right libraries.