On the IBM developerWorks site today there's a new tutorial showing you how to store shared data directly to a shared memory space of your PHP application.

Once created, and given proper permissions, other processes in the same machine can manipulate those segments by: read, write, and delete. This means that an application written in C can share information with an application written in other languages, such as Java or PHP. They can all share information, as long as they can access and understand that information. [...] This article's proposal is simple, learn how to create and manipulate shared memory segments with PHP and use them to store datasets that other applications can use.

Your PHP installation will need to have been compiled with "enable-shmop" to work with the code in this tutorial. Their examples show how to use the shmop_open, shmop_write and other related functions to read, write, remove and close segments in the shared memory space. They also include an example of using the SimpleSHM library to make it easier to interact with the shared memory space as a standard storage location.

In this new post to his blog, Johannes Schlüter looks at a high-performance solution to the usual storing PHP session information via a memcache frontend with a MySQL Cluster backend.

Unfortunately even such a system [using MySQL and InnoDB tables] has limits and unfortunately replication is no good solution here to scale further as we will always need a master for writing the updated session data. By using replication we can take some load from it and we can configure a slave which can be promoted to master to keep session alive if the primary master machine fails but at some point in time we need another solution ... but, happy news, again: One doesn't have to look far as MySQL cluster will be happy to help. MySQL Cluster "is a high-availability, high-redundancy version of MySQL adapted for the distributed computing environment," as the MySQL documentation states.

He describes the setup (after pointing to this post about installing MySQL Cluster for memcache) and includes some sample code/SQL/ini settings you'll need to use to get PHP's memcached functionality to cooperate with it.

Andrew Martin has a new post to his blog looking at a technique that could be used to help minimize some of the performance issues you could see on AWS micro instances dealing with PHP session handling. His alternative is serving them from a RAM-based disk instead.

It's rare to find a web server with slow disk I/O performance, but Amazon's EC2 micro-instances are one such example. Their EBS disk subsystem access is rated "low", and this can have a detrimental effect on HTTP throughput. [...] This leaves sessions, which can be written to a redundant and fault tolerant storage system. [...] In order to speed up the disk access, a RAM-based disk can be mounted over the session directory. This has the disadvantage of being volatile - the data is lost in case of a server reboot, or the mount point being unmounted. However if tolerable, storing sessions in RAM insulates the application from poor filesystem performance.

He mentions the two types of kernels that can be used, ramfs and tmpfs, and the specifics of using a tmpfs filesystem to implement the technique (complete with command line calls to make it happen).

Jonathan Bradley has submitted a handy new helper for the CakePHP users out there that can help to work with Google's Storage in a drop-in plugin - the Simple Google Storage Plugin for CakePHP.

Ever noticed how there is no decent support for CakePHP to utilize Google Storage? Well the wait is over, after realizing that Amazon S3 was just way to unreliable and bloated with spammers and usuage hogs. You can now add Google Storage support to your CakePHP application.

Obviously you'll need to be set up with Google Storage before using it, but the tool makes it as simple as calling publish() to push the data out, return all of the bucket information for your account and pull out information about individual objects. There's also a method that lets you make new buckets on the fly to make categorization simpler.

The heart of the code lies in the Storage class, so if you want to see how it's done, check that first. Other frameworks have their own interfaces with the Google services too, like the Zend Framework's Zend_GData component.

In a recent post to his blog Brian Swan shows you how to use the Storage Emulator for Azure with PHP via their provided SDK. It's a quick post but it has a helpful code snippet if you've been struggling with getting it set up.

This is a short post to address this question: How do I use the local Storage Emulator (formerly known as Development Storage) when using the Windows Azure SDK for PHP? The Windows Azure Command Line Tools for PHP provide an option for running an application locally in the Compute Emulator, but I didn't see an option for using the local Storage Emulator. As it turns out, the answer is very simple, although somewhat difficult to find.

The trick is to omit the constructor parameters when creating a new table/blob/client to get it to create things locally instead of on your Azure instance. He also includes a set of links that can help fill in some of the gaps in the whole Windows Azure deployment process.

Brian Swan has a new post today looking at how you can update some PHP settings in your Windows Azure instance - an alternative to redeploying your every time your php.ini file might need an update.

I came across this question on Twitter last week: "How can I turn display_errors on for an application that is running in Windows Azure?" I have to admit that I was stumped. The only thing I could think of was to re-deploy the application with an updated php.ini file. But, I happened to mention this question to Ben Lobaugh who suggested a very simple idea: Store your PHP settings in some durable store external to your application as key-value pairs, then loop through the settings and update them with the ini_set function when a page loads.

He puts a big disclaimer on his suggestion, noting that it's "a hack and only a hack" and can be useful for someone still learning how to work with Azure and deployment. He shows how to use a Table storage to save the values and make them easier for the application to grab at runtime. Using the tools from their SDK, fetching and setting those values is a simple process. An idea like this, while convenient, could potentially cause performance issues down the line, do be careful with this recommendation (and be sure to load test).

New on BinarySludge.com today there's a tutorial looking at redundant and fault tolerant session storage via a few different technologies that can store session data with a custom session handler.

If a PHP application has deeply embedded usage of the $_SESSION superglobal, removing state is difficult. Instead removing the dependency between a user's session data and the single server it's stored on achieves the same fault tolerance.

They focus on a REST-ful approach to session handling, that it should be "kept entirely on the client" so there's no issue if something happens to the primary session data source. They point out that, while the technologies that can be used to replace it are similar, there's still some issues around using things like memsached, Sharedance, Hazelcast or MySQL to store session details.

Johannes Schluter has a new post to his blog on another PHP internals related topic - hashtables.

While preparing my "PHP Under The Hood" talk for the Dutch PHP Conference there was a question on IRC about extension_loaded() being faster than function_exists(), which might be strange as both of them are simple hash lookups and a hash lookup is said to be O(1). I started to write some slides for it but figured out that I won't have the time to go through it during that presentation, so I'm doing this now.

He talks about array storage (a "real" array), numeric and string-based keys, the internals of how each is stored and how the differences make the one function faster than the other (hint: it's all about collisions).

Brian Swan has posted a new tutorial to his blog showing you how to connect your PHP application with the Azure service and use the blob storage it offers.

In this post I will do something similar [to this previous post] for accessing Windows Azure Blob Storage from PHP. This won't be a deep-dive into Windows Azure Blob Storage, but it will be a "how to get started with the Microsoft_WindowsAzure_Storage_Blob class (which is part of the Windows Azure SDK for PHP)"-type post.

He talks about how these blob containers are stored on the Azure side and what kind of access controls they come with. This graph might help sort it all out. From there he shows you how to use the PHP SDK to connect to the service, make a new container (with an ACL) and doing all of the usual operations with a blob - uploading, downloading, streaming, deleting and listing the blobs currently available.

Brian Swan (of Microsoft) has a new post to his blog today looking at using the Windows Azure Table Storage from inside of your PHP application.

An overly-simplified answer: Windows Azure Table Storage is structured storage in the cloud provided by the Windows Azure platform. It allows you to create any number of tables, which can each contain any number of entities. Each entity can in turn contain any number of properties. A picture is worth a thousand words here.

Think of it as almost a Microsoft-created version of a NoSQL database engine. He shows you how to get started by making an Azure account and setting up a new project for you to work from. Then, using the Azure SDK, he shows how to easily make a connection and do all of the usual CRUD (create, read, update, delete) operations on this new project.