I'm pondering the use of S3 as a poor-man's load balancer / Akamai solution. I've already mounted (several different ways) S3 partitions using FUSE. I've mainly done it on the EC2 instance for immediate backup purposes. Amazon has now released their persistent storage solution for EC2, but there's much debate on the cost effetiveness of it all compared to mounting an S3 partition.

I personally found PersistentFS to be extremely good because you have a great deal of control over how your data is being accessed and what to expect in your monthly AWS bill as well as control it.

So of course a cache system needs to be fast. I would suspect Amazon's EBS to be the clear winner in that department. So mount one of those and store your CakePHP /tmp/ folder there...or why not the entire application at that point? Sure then we're making a moot point out of what I'm after.

I'm after a very specific thing here. I'm thinking about how S3 is mirrored and I'm focusing on it's advantage. Cheap High Availability and the power to offload strain on your server. Therefore, a pure S3 implementation is better than using the EBS because nothing goes through your server. In fact, your server can be down and your data will still be on S3. Also, I'm looking at the people who aren't using Amazon EC2 and/or don't have the ability to use FUSE. What about shared web hosts?

Naturally storing session data and other persistent data like that wouldn't be good. So in my thinking that leaves the model and persistent folders of the cache directory of CakePHP out. Again, I'm focusing on a specific purpose here. I'm targeting the view caching. 

My question and research is now geared toward performance issues with view caching. So not all caching that CakePHP does, just specific types. So I guess a hypothesis would be: If the view cache folder is stored on and read from Amazon S3, then loading pages in CakePHP will be faster. 

Is that true? I don't know. I have to think about performance issues...again, we're not just saying "here go load this file" when we load up view cache. There's other classes responsible for talking to these files. So the server hop may create an issue that slows something down...If so, is it to the point that it's detrimental? Is it a trade-off situation? Have a million visitors hit your cached page at once just a little bit slower than normal, or don't handle a million visitors at the same time? I'd personally rather handle some sort of digg effect a little slow than not at all. 

I also have to think about the assets. CSS files, images, javascript, etc. So does the webroot folder have to be on S3 too? Is there a way to maybe have the engine store and look for all those assets on S3? 

Something I'll be experimenting with and asking around for opinions and things I haven't thought of. However, it would be great to setup a "load-balance" solution for common files and assets for shared hosting. I know you can serve all your media off S3 from a shared host quite easily ... but a plug and play solution for CakePHP to do that would be great. I imagine that would help a lot of sites get more life out of a shared hosting solution.

AMFEXT, the AMF extension for PHP allows data to be encoded and decoded by the web server much faster than other conventional remoting systems, such as AMFPHP, WebORB, etc. Since the extension is programmed with C and runs as an extension to PHP rather than a script, it encodes and decodes AMF messages much much faster. More information about AMFEXT here. 

There has been great efforts made by some people in the CakePHP community to use this extension with the CakePHP framework at a virtually transparent level. This continues the efforts of rapid development set forth by CakePHP. Simply by setting up the data for your views normally, you have the same data available to you through the gateway in Flash / Flex / Actionscript. It utilizes the new AMF3 encoding as well. It's lightning fast! 

The benefits are great and there's many possibilities now available to us. Think about tools to update blogs and other CMS' ... Think about various business type applications, since Flex sets us up with such great interfaces. Now combined with CakePHP, think about the scalability options; the use of multiple databases, the caching, and speed of development. Especially combined with the Flex framework. It's a great combination. Far better than most known remoting methods.  

I've setup a demo of CakePHP using AMFEXT with a simple search. Simply pass in a string to search the database for. There aren't many rows of data, but I'll add more. Here's the Flex view: http://www.etrcloud.com/amfext/amftest.html

Here's the normal HTML CakePHP view: http://www.etrcloud.com/amfext/names/retrieve/a
Note the a on the end of the URL is the string that's being passed to search for. Change it to some other characters to see. You can also see the SQL query that's being made.

So perhaps the biggets down-side (and I hope not the Achilles tendon) of Amazon EC2 is the lack of persistent storage ... out of the box.

Your data will be lost if your instance crashes. What are the odds? It depends on Amazon's reliability I suppose -- but also how clean you keep your server instance. Or even perhaps how many people hit your site that might cause some sort of instability. Maybe??

Anyway. There are persistent storage options through third party sources and Amazon is going to be providing persistent storage for EC2 soon which may make all this moot.

There are two big options that you have right now and with them you can mount an S3 partition like it was a physical local drive on an EC2 instance. It works quite well. There's ElasticDrive and PersistentFS.

I'll be comparing the two here soon. I have used ElasticDrive, and I'm going to use PersistentFS next. Differences? From what I can tell, slight and maybe they don't even matter for most users. There's a forum thread here where the two kinda duke it out. There's also this forum thread where I was asking a bunch of questions and very kindly someone at PersistentFS was very on top of everything. Perhaps that thread got off track it was originally about Amazon offering a persistent storage solution...which would make things like ElasticDrive and PersistentFS useless? Maybe. Maybe not. Probably not in the case of mounting something other than S3...but it may not be good for them. Though the thread is now moving off to discussions about reliability and how things work. Which is nice, contrasting current web hosting standards or practices with the Elastic Compute Cloud is very interesting. 

I just hope Amazon's persistent storage solution isn't outrageous. I don't think it's fair to pay extra for it...to a degree. I would expect it to cost money for a certain amount of space...But I would also expect a certain amount of persistent storage to come with each instance based on its size. We'll see what Amazon has in store for us soon...Until then, I'm going to check out other solutions and report my findings here. 

So I changed up how videos are converted to FLV. I made it an action an admin needs to perform after uploading videos. I will also re-implement a cron job that can be controlled from the admin back end.

This pretty much puts the installation here on par with, if not slightly ahead of, the Minerva Blog installation. The next thing is of course to get it all setup with EC2 and load balanced/clustered. Aside from making a nice default theme to use. Can it be? A real working demo ready to show off? I sure hope. 

Well, it's back to the original task at hand now that I'm catching all up -- Working with Amazon EC2.