If you’re running a CMS with dynamic redirection using mod_rewrite on DreamHost, you may run into a problem trying to access your statistics – since the .htaccess file specifies files and links, and not server configuration redirects like the /stats/ directory, you can be in a bit of trouble. When you try to access the /stats/ virtual directory, the url will get rewritten, your CMS will get confused, and you will get an error instead of seeing your precious website statistics. I had been using Google Analytics, but that requires that your website’s code be loaded in order for the stats to be generated. This does not catch hotlinking or deeplinking into images or other media. 

I had been searching for weeks on how to write a mod_rewrite exception, but anyone that knows mod_rewrite code knows it will make you want to jump off a cliff. It’s honestly almost as bad as writing a config file for sendmail or bind before they introduced the structued layout.

Today I had a thought, since this problem is nearly unique to DreamHost, why not search there for potential solutions to the problem? 10 minutes of digging in the DreamHost wiki and I had my solution – Making stats accesible with htaccess – this simple rule inserted before your permalink rules allows a catch and exception for the /stats/ virtual directory:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/(stats|failed_auth\.html).*$ [NC]
RewriteRule . – [L]

For those of you on shared hosting with Dreamhost – we all know they’re oversold up to their eyeballs. While the prices are great and the proposed services offered are even greater, their servers are overloaded and very slow. Very very slow. I took a dive into their wiki today and found this gem: PHP FastCGI 

After a few seconds of careful mucking in the .htaccess file, and writing a new spawn script for the PHP process, I have sped up a few of my websites by a noticible amount. WordPress wasn’t exactly the most efficient CMS either, so this in combination with WP-SuperCache has made the loading times…liveable…for now.

Normally, Apache server spawns a child process for each request on the website (overly simplified) – each one of those child processes then reads your PHP code and makes the HTML output that you see on the website. It works great, except when you have eleventy billion people on your website, or in my case, an overloaded web server. The process of spawning a child process, then forcing that child process to intepret its own php code is very resource intensive. So what do we do to fix it? 

The hack above makes two discrete child processes that process php code. Those two are it – which is great because instead of spawning, starting, processing, stopping, despawning each time a visitor hits the page, you just do the processing, which makes things go much quicker. The downside is the website may not scale well to unexpected spikes in traffic, like a Digg or Slashdot. But I have that covered as well – chances are the content you see on my is all static HTML. There is a script that runs in the background that runs all the php code beforehand to generate the pages. When a visitor comes along, all that is served along is the static html page with no hits to the php intepretor. Only when the content changes does the php get hit again. Great for now, but I hope to get a more powerful server in the future.

If you’ve ever wanted to combine lots of PDF files into one large multi-page PDF file, and you want to do it with legal, free utilities, give PDFTK Builder a go. Can also change PDF permissions!