You just finished your install of Apache, PHP and APC cache on a VPS and you're beat. You spent about a day going over every configuration and compile option trying to eek performance out of your VPS machine and web server. Then you take a look at the output of top or ps and notice, hey, my Apache process is 150 Megs! Well isn't that grand....

Drupal multisite setup configuration

I've adopted Drupal for a majority of my online activities in the past year. It has enough of the things I like and is much faster and more stable than previous CMS or forum software I've used. However, some documentation seems to be lacking. Multisite configuration with Apache using a single Drupal codebase is one area.

I finally decided to try a project in which I would use a common codebase for Drupal across all of my websites. That is, rather than having a directory for each website that has a Drupal installation in it, I thought I would take advantage of Drupal's multisite functionality by having one drupal installation (codebase) in a central directory and have all the project websites point to it.

In this article I want to talk a bit about standards. Not necessarily standards like you'd find with W3C, and not code formatting standards, but coming up with a consistent plan as you code and sticking with it. Staying close to the PHP manual and following developments with PHP so you don't get bit in the butt later. I've been working with PHP for some years and have seen it go from version 2 through the current version and there have been many changes along the way.

In particular, I was thinking of two specific situations from my past which can bring down a site unexpectedly.

Shared Hosting

Lately people have been blaming PHP for being insecure. While most of them seem to blame little tiny issues that, when used incorrectly by the programmer, make their scripts insecure. Does that make sense? The programmer uses it insecurely, but the problem is in the language. Absurd. Guess what, you can do that with any language. You can make your house insecure too by failing to fasten the door locks. But more to the point, after examining some of the Blog and CMS software for PHP I've come to this conclusion - if that kind of programming is general across the board for these packages then we have a bigger problem.

Just yesterday I talked at length about the caching benefits of the Smarty Template Engine for PHP. Today I was able to see an example of why caching was such a good idea.

In that article I used an example of an e-commerce store that had a page with three 'Top 10' lists. The 3 variations were for 3 different time periods, and the 'all time best sellers' list was a killer SQL query that had to look through 6 years worth of sales records to determine the top sellers. I used Smarty's version of template and page caching for the script which caches the output in a PHP file. I then chose to regenerate the cached file once per day resulting in only one database connection and query PER DAY instead of one query every time someone viewed the page.

I never thought I would need to worry about caching. Hardware these days is fast. But the more I thought about efficiency the more I realized that my pages don't change that frequently so why go through the overhead of connecting to a database on every page load? Or for that matter, why load a static file, unserialize something stored, recalculate the 'year' in the copyright tag. For that matter, why perform any of these tasks every time the page is loaded when they may change infrequently? Well, luckily Smarty has caching built-in and I found a use for it.

From the Smarty web site:

I was reading some PHP blogs last night just to pass the time when I came across one entitled something like "Smarty is evil."

After reading the post I concluded that the author gave Smarty a fair shake, and indeed, acknowledged that this was his own opinion based on a first impression during a very short time examining the Smarty Templating system for PHP. In my opinion, I would consider this author to be a fair designer with logic because he is able to discern his own emotional opinion from the true facts. A trait hard to find in those who work with computers who are many times very opinionated and highly defensive. Kudos to the author for getting past that.