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.

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.

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).

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.

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.

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).

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.

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).

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.

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.