Just today I was challenged with a project that will require value caching in a PHP/MySQL cluster environment. This project will have to deal with loads of up to 500 requests per second, most of which will involve writes. When working on a small scale it is easy to forget the latency issues associated with all engines in MySQL. This project will require a massive read/write caching system that will sit between PHP and MySQL and will require full data persistence. I found a valuable article that shows some of the timing differences of the popular storage systems under load. Redis seems to be the real winner here. With write-only data persistence (write to disk), this storage engine still comes out on top! This is truly the best system if you are caching write calls to MySQL. This way, most of the data will survive in case of a crash. Persistence can be increased even further by using another fully redundant Redis server. This is a must have for high-load write caching.

Hey guys, keep tuned for updates on CRG Studios’ upcoming simulator: Structure. It is past concept and will soon be impacting your world. The engine this will be using will be my open source T2 Engine. This game will be cross-platform, hardware enabled and terribly awesome.

A while back I ran into a problem settings up a new version control system for our in-house PHP intranet. We have multiple developers working on the intranet at one time, and we needed to maintain independent working environments that we could use to test the overall effects of our code on the entire intranet without interfering with others working copies or with our main development repository environment. We wanted all web hosting for the main environment and independent environments to be done on our development server.

After setting up SVN and a repository for the intranet files, I had to figure out a way to set up the web hosting. In order to provide hosting for all individual copies and for the main copy I had to set up network drives for each user. Each individual copy was in a named folder all under one common folder. I used samba to allow users to access their files and set up apache to serve the PHP content out of each folder. Each user then mapped the folder on their workstations and used whichever SVN tool they wanted to check out the files into their new network drive. Their individual copies were now set up and ready to use.

This system is meant to manage the content for our development copy of the intranet only. After files were pushed through SVN they should then appear in the main development checkout. I set up a cron job to pull updated files from SVN and put them into our primary copy of the development intranet. This was our main beta for our changes to be tested and that primary revisions would be pulled from and pushed live.

This was the best solution I could come up with for this problem. To my surprise I didn’t find anybody else on the Internet with similar problems. This way seems to work just fine for us though and will hopefully help out anybody else looking to manage a project like this.