However, I knew the hard drive likely contained old checked-out code that had been moved to a new machine. I'm not a super-paranoid guy, but there's enough horror stories out there that I'd rather wipe an old drive if I have the chance. So I popped the drive out and hooked it up to my Windows XP box.

I wasn't really surprised when I booted XP and couldn't see any sign of the drive. I cruised over to Device Manager, and it showed up there, but you can't format or mount drives from Device Manager. I was a bit vexed, moreso because I wasn't sure what kind of file-system was on the drive. Was it a linux ext2/ext3, or a FreeBSD UFS system?

I came across a nice post that pointed me in the direction of a great tool called Ext2 Installable File System for Windows. It installs a Control Panel that lets you mount and access ext2/ext3 drives. I gave it a shot, and it even picked up my drive and allowed me to assign it a letter during the install, so by the time I was done, Z: was waiting for me!

It turns out that the drive was UFS however, so when I tried to access it, I got a "This drive has not been formatted" message. That was enough for me though, as I could now quick-format it with NTFS, then access it with my erasing utility, eraserd.

A couple of quick commands into a DOS prompt later:

eraserd -allfiles Z: -passes 3
eraserd -disk Z: -passes 1


and this hard drive was all set for it's trip to recycling, and I was assured that nothing wayward will happen to any old data that might be on it. The first command removed any known files on the disk (which was none, since I had just formatted it), and the second command then used a secure erasing algorithm to overwrite all free space on the disk.

Because I wasn't using the XP machine for anything else at the moment, I re-formatted the disk and re-wiped the free space two more times. Maybe I am super-paranoid.

So here you go… may I present Blake's CentOS LAMP Server Guide, single-page edition, and the perhaps friendlier multi-page edition.

The guide covers the basics of building up a CentOS box to use as a remotely-administered LAMP server, including installation and configuration of PHP, Apache and MySQL. Other goodies are in there too, like mail server setup with Postfix/Postgrey/Dovecot. Keep in mind this guide was written from my point of view, and contains the ways that I like to do things. I keep my basic LAMP stuff pretty slim for maximum performance, so you'll see some installations from source in there to help keep things tight.

Let me know if the guide is useful! I'm hoping to get Google to pick it up and get some comments going on the various ways people set up their own LAMP boxes.

Now, the cleverer ones amongst you will know that Apache Benchmark, or ab, will do pretty much the exact same thing, plus much more. This is where I was planning to get my first batch of results from. But something has happened that is leaving me puzzled as to how I'm going to make these tests fair.

I ran a few benchmarks against a basic PHP page, and it was pretty consistent, within the realms of what you'd expect for a page just coughing up the same content over and over. When I ran the same benchmark against a similar .aspx page however, things were not consistent!

Mono benchmarks -- an anomaly

Without going into a long post about what all results were, here's a brief summary. I originally noticed the problem when I ran ab -n 1000 -c 10 [url] from a remote machine that is on the other side of the country. ab was given a PHP URL and an ASP.Net URL for the test server here on my home network, and dutifully returned results for each. The PHP page was giving me results similar to the following (results in seconds for total test time, rounded for brevity):

75, 75, 74

Looks good. Kind of what you want to see in a benchmark. Predictable load times under a given circumstance means your application code is working predictably as well. I ran three tests and averaged the results. So what did I get from Mono? I restarted apache, hit a page to get rid of the initial .Net load time, then ran three tests. Check this out:

77, 77, 100

I thought that was kind of weird. Maybe the server was under some sort of load I didn't know about, so I thought I'd chuck the third benchmark as anomalous and run some more:

95, 107, 92, 106

Now I had a case of the WTFs. Thinking something was wrong, I rebooted apache (and hit a single .aspx page for the initial .Net load). Then I ran some more tests:

restart, 78, 79, 92

There it goes again! I switched to testing on the server machine itself under my desk to get rid of any network latency that might be occurring cross-continent. I ran some PHP benchmarks to see what I would get.

51, 51, 66, 52, 51, 51, 51

Looks good, save the spike in the middle. Back to Mono:

restart 56, 58, 61, 62, 68, 62, 63, restart, 57, 61, 61, 63, 67

WTF

It quickly became evident that the Mono environment is accruing some sort of overhead the more I pound on it. And it's not getting away from this overhead either. I left it alone for awhile to gather its thoughts (and maybe its garbage) while I took a break, but when I tried again it still showed much higher benchmark times than it would right after a server restart. The conclusion I came to over another hour of testing is that Mono would never serve pages as fast as the first benchmark on subsequent benchmarks.

This has delayed my actual collection of benchmark data between PHP and Mono ASP.Net, as I don't feel that it's a fair comparison between the two if Mono is accruing performance penalties the more I use it.

I'm going to have to research this a bit more. Maybe it's my configuration, maybe it's Apache, maybe it's mod_mono, maybe it's something wrong with the .aspx test page, maybe it's a spooky goblin. Maybe it's Mono itself. I don't have enough information at this point to be sure. I'll have to try to narrow this down, or continue testing knowing this limitation.