August 13, 2014
March 2, 2013
I’ve been playing with the Yii PHP framework for a while now. I evaluated several PHP frameworks and found that I liked Yii the best.
- I publish my assets into a sub-folder of the assets folder, so often times the modification timestamp on the assets folder wouldn’t get updated and I would still get old assets
- Since the url used to access the assets contains a hash based on the modification time of a folder on the filesystem, you could run into issues if you have multiple load-balanced webservers with different modification times on that particular directory.
I decided I still wanted everything I gained by using the AssetManagement paradigm, I just didn’t like how it hashed things and tracking down caching issues isn’t how I like to spend my time. I introduce to you the VersionAssetManager (available in this gist on Github for now).
I didn’t change much from CAssetManager except what it’s hashing. Traditionally, CAssetManager hashed the path + the Yii version + the modification timestamp. My VersionAssetManager hashes path + Yii version + application version.
Did he just say application version? I sure did. Every time I deploy my site, the verision number gets incremented. I use jenkins and package my sites into RPMS. As part of the build, Jenkins adds a file to the rpm called version.php that contains
<?php return '1.0.<jenkins build number>';
This gets loaded in my config/web.php:
//... 'params'=>array( 'version' => is_file($protectedPath . '/config/version.php') ? require_once($protectedPath . '/config/version.php') : 'Development'. //...
Now I can access Yii::app()->params['version'] anywhere in my application. You may notice a problem though. In my development environment, version.php doesn’t exist, so the version will always be set to ‘Development’ and thus my hash will always collide and won’t bust cache. To bust cache in development I decided to hash the asset’s path + the current time. This means that every pageview will generate a new hash (unless you have multiple pageviews during the same second) and thus you’ll be making copies of lots of assets into your assets directory which you’ll pay for in both disk space and page load time, but you’ll never have to worry about busting cache during development.
Now I don’t have to worry about busting cache while developing and when I load balance my site to multiple web servers, they will each use the same hash based on the application’s version number to access the assets.
January 11, 2013
I have been testing Redis at work getting familiar with the various modes of persistance. Usually I treat Redis like memcache and disable persistance, but we have a use case that requires us to persist the data.
I started playing with the RDB and AOF files and stuff. One thing we wanted to test was how long it takes to load the files on startup with a large data set (large for us is 10GB or so). I loaded up the instance, called the SAVE command, then restarted redis. Looking at the INFO command you can watch it load the file. This was okay, but meant I had to manually telnet in (or use the redis-cli app) and run the command. What I wanted was a simple progress bar that showed me the loading progress, so I wrote a little script to do just that. You can find it on Github.