Recently, I needed to sync several directories on a backup / fail-over server with the same directories on a production server. Rsync over SSH takes care of this, but if you want to tighten security, you must use the “command” restriction in the SSH authorized_keys file — This restricts the authenticated key to running a single command, with a specific set of arguments. For example, let’s look at a typical command that might be run from a backup server to rsync daily database dumps:
backup$ rsync -av --delete -e "ssh -i $HOME/.ssh/prod-rsync-key" \
A few weeks ago I mentioned the wesley.pl script from GitHub to optimize images, and how I had modified it to keep (or discard) the EXIF / XMP information. Making sure images are as small as possible is important to save bandwidth and improve page load times (and google rank), so I think it’s worth discussing my image optimization process in more detail.
To improve page load times (and Google ranking), you should make sure all jpeg, png, and gif files are properly optimized. Instead of writing my own script for jpegtran, pngcrush, and gifsicle, I used Mike Brittain’s Wesley.pl script on GitHub. It works great, though I did have to modify it to change the “jpegtran -copy” parameter it uses — I need to keep the EXIF on larger files, and strip it from thumbnails. I posted the diff on the GitHub Issues page.
Update 2012-12-31 : In case Mike doesn’t merge my diff, with the addition of the
--copy=[all|comments|none] command-line argument (see my comment bellow for more info), you can download the patched wesley.pl script here instead.
I wrote a bash script this morning to report the size of WordPress cache folders, the number of files they contain, read each file to prime the OS disk cache, and optionally flush the OS disk cache as well. This might be a script you could execute to email a daily/weekly report of cache folder sizes, or perhaps execute during/after booting a server to prime the OS disk cache, or even on a regular schedule to make sure the OS cache is always primed. The script also has a “flush” argument to sync and drop the OS disk cache, which isn’t very useful (to me) except to see the difference in speed between a clean and primed cache (about 11s vs 0.4s for all websites on my server).
I recently added some disk caching for MySQL queries, WordPress objects, PHP opcode, and PHP web pages on my server. There are several different caching techniques and applications available, and memcached seems like one of the more popular ones. Right or wrong, it appears to be the default go-to for many developers these days.
Since I’m a SysAdmin by profession (with maybe a penchant for scripting and integration), I tend to have a more “systems” oriented approach — which led me to first consider, and then choose disk caching over memcached. In this post, I’ll outline the reasons I chose disk caching, and why in most circumstances it might be superior to memcached.