In this new post to his CodeDiesel site Sameer Borate looks at something that's been a controversial topic with developers (not just PHP) about storing binary data, like images, in a database instead of on the local file system.

There is much discussion and argument with no final say on the issue. In one of my recent project the same issue was raised; the client and myself discussing the benefits and drawback of storing the images into a database. The project needed storing around 50,000 images, so it was important to get the question resolved satisfactorily. After much deliberation we settled on using the file system. The major factor in the decision was that we needed the database and images decoupled as we would be having multiple databases using the same set of images.

He goes on to talk about some of the things you should consider when you're deciding if storing images in the database is the right thing for your application including:

• The bloat that can come with storing binary data (larger database size)
• Updating images requires two operations - updating the database and updating the cached image locally
• Images usually serve faster when they come from the filesystem through the web server
• BLOB (a common type for binary data storage) is variable-width and can degrade performance

You can read the rest of the reasons (and get more detail on the ones above) in the rest of the post.

Patrick van Kouteren has a new tutorial posted to his site showing you how to connect your application with an OpenStack instance (specifically the CloudVPS option) via some simple CURL commands (easily translatable into PHP).

Lately I've been playing around with the CloudVPS ObjectStore, which is currently in beta phase. This blogpost shows the options of this ObjectStore in a practical way and concludes with a summary of commands you can use yourself to interact with it and some ideas. For this post, I assume you are familiar with cURL, REST and HTTP headers.

He shows how to make the requests for:

• Authentication
• Working with containers
• Adding files to a container
• Setting access permissions

Michael Nitschinger has a new post to his site today showing how to implement Couchbase as a storage mechanism for your session information (including some handy extra features).

What do I mean by flexible? Well, the combination of a highly scalable key-value store and the possibility to query your data through views allows you to gain unique insight inside your data in near realtime. [...] Let's look at some obstacles that we as application developers face and then see how we may solve them through Couchbase and its functionality.

He talks about some of the options to track user sessions (both on the server and client side) including PHP's sessions, HTML5 data storage and memcache. He covers some of the most basic session tracking needs and shows how to use the CouchBase extension to work with and setting some key/value combinations for user sessions. He shows how to query these data structures (JSON data) and filter to find only the records needed

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.