Trying to keep your data updated to a database while undergoing heavy traffic can lead to a very slow response for your queries. Ever wish you could push your writes to a queue so they can be handled during system time and not user time? It’s pretty easy. This model requires there to be a non-disk key/value data store (Redis, memcache) available that can act as a forward cache. This works better if the system can support lists. If an object does not exist in the forward cache when asked for, it needs to be pulled from the database, assembled and stored in the forward cache. When an object is updated, it needs to be updated in the forward cache as well as being pushed to the write queue. This way your user script only accesses the forward cache and the write cache during standard calls when the cache is already populated with the needed data.

This trick can be enhanced even further by storing a list of unique IDs in the write cache that can be replaced when an objected is updated before one of it’s previous writes was processed. This means that what would have been two database writes is now one! This requires storing a list in cache as well as the objects, which is done very effectively with Redis.

When used correctly and with a properly designed database that reduces the number of unique objects, your writes are faster and fewer! With a few more tricks this system can also be used easily and effectively in a cluster environment. More on that later.

I use Eclipse for all sorts of stuff including Zend PDT, Android SDK and C++. I like to keep my desktop looking well organized and looking professional. I never liked the default Eclipse icon that came with the Linux installs, so I made my own for Eclipse and Zend PDT icons with transparency that look snazzy with blending in GNOME panels or Avant Window Manager.

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.