till's blog

A Fan Error in this case is not when your Facebook fan page is down. I received this message after my Lenovo X61s notebook decided to quit and I restarted it. The screen said "Fan Error", and the notebook refused to continue to the boot process.

A rescue party

Of course this is the last thing you want on a Sunday evening, but in true GTD fashion, I wanted to fix it right away. Here's how.

Precaution

In order to not electrocute myself, I removed the battery and unplugged the notebook.

Get in there!

I basically unscrewed every screw there is at the bottom of the notebook, until it would let me remove the upper part of the casing and keyboard.

Then I tried to carefully clean the inner of my notebook from dust and dirt that accumulated over the past 14 months since I purchased it. I think had dust (and what not) from North America, Europe and South America in there. It was kinda gross. It really didn't look pretty. And that is despite all efforts to not eat and drink near it.

Fan

When I got to the fan, it wouldn't really move. Hence the fan error!

I forced it a little and white dust came out of it. So I decided to take more drastic measures and sucked it clean using my Dyson. In the beginning it wouldn't really move, but it took only a minute to resolve that. (Word of advice: If you are not super careful, the Dyson will try to suck in whatever it gets. So make sure to not vacuum the insides of your notebook. ;-))

Reassembly

Reassembly is pretty simple. The case clicks, and then you fill in the screws. IBM/Lenovo were smart enough to only use screws of the same type. There was a total of ten (or maybe nine), and they are all gone. So that must have worked.

Conclusion

Don't try this, unless you have to. And know what you are doing. This blog entry comes with no guarantees or extended warranty. Being able to fix little things yourself, feels good though.

This is not (really a part) two of my series, but an Intermezzo (1) between Part I and Part III — because I have no time to finish Part III.

In Part I, I talked about my approach to deploying a website and I offered pear and subversion as solutions to the problem. To briefly elaborate on my subversion part, I want to share the following Capistrano recipe with you.

Capistrano, isn't that Ruby?

Yes it is! Capistrano is a nifty piece of software. Not because it's so super-duper complex, but because it's pretty robust and works really well.

I am sure everyone heard of the "the right tool for the job" theory and this is along those lines. Please don't be afraid of a little Ruby to ease the deployment process. (They don't deserve your fear anyway. ;-))

Installation

On FreeBSD:

cd /usr/ports/devel/rubygem-capistrano && make install clean

On Debilian/Ubuntu:

apt-get install rubygems
gem install capistrano

Go on and create a capfile in $HOME, and this is where we'll keep our tasks.

Here's a little HowTo on how to setup CouchDB on an AWS EC2 instance. But outside of AWS (and EC2), this setup works on any other Ubuntu server, and I suppose Debian as well.

Getting started

The following steps are a rough draft, or a sketch on how to get started. I suggest that you familiarize yourself with what all of these things do. If you want to skip on the reading and just get started, this should work anyway.

• you (obviously) need an AWS account (and log into the AWS console).
• you need a custom security group (make sure to open up for http traffic)

• create an EBS volume (Take a deep breath and think about the size of the volume. Keep in mind that you don't want to run into space issues right away and that allocated storage (even idle) costs you money (e.g. 400 GB =~ 40 USD (per month), excluding the i/o).)
• create a keypair (It'll prompt you to download a foobar.pem, I placed mine on my local machine in ~/.ssh/ and ran chmod 400 on it.)
• get an elastic IP
• start the instance
  • select an AMI (I selected alestic's 64bit server Ubuntu 9.04 AMI.)
  • assign your own security group AND the defaults one
  • select your keypair

Woo! We made it that far.

The instance should boot and once this is done (green indicates all went well), we want to associate the previously created EBS volume and the elastic IP to said instance.

Once these steps are complete, go on the instance screen, click on your running instance and then click on "Connect". It'll show you the ssh command to connect to your instance -- it should be similar to this:

ssh -i .ssh/foobar.pem root@ec2-W-X-Y-Z.compute-1.amazonaws.com

The W-X-Y-Z part is most likely replaced with your elastic IP.

This process is not very automated yet, but at least you have an instance up and running. The next step is to try to login and see if the EBS was attached — if all went well, you should have /mnt.

Moving our PHP application into the cloud, means for us that we are leaving FreeBSD for Linux. Not the best move (IMHO), but I shall elaborate on this in a future blog post.

Once we decided on Ubuntu as the Linux of our choice, I started by moving our development server to an instance on Slicehost. Point taken, Slicehost is not the cloud (as in Amazon EC2, Rackspace, Flexiscale or GoGrid) yet, but Linux on Slicehost and Linux on Amazon EC2 will be alike (or so I hope :-)) and a getting a small slice versus getting a small EC2 instance is an economical decision in the end.

Introduction

The following is the start script for my php-cgi processes, which I ported from FreeBSD (I previously blogged about it here).

The advantages of this script are:

1. php-cgi runs on a unix domain socket — no need for tcp/ip on localhost.
2. No need for the infamous spawn-fcgi script, which never worked for me anyway, and on Ubuntu requires you to install lighttpd (if you don't happen to be on Karmic Koala).
3. You can setup different websites with different instances of php-cgi. This is great for virtual hosting, especially on a development server where the different workspaces may have different PHP settings and you want to run versions in parallel without sharing settings and therefore maybe affecting each other.
4. Icing on the cake: we could even add a custom php.ini to the start call for each instance (-c option) to customize it even further.

Since part one and two were uber-successful, here's an update on my Zend Framework PHP performance situation. I've also had this post sitting around since beginning of May and I figured if I don't post it now, I never will.

Disclaimer: All numbers (aka pseudo benchmarks) were not taken on a full moon and are (of course) very relative to our server hardware (e.g. DELL 1950, 8 GB RAM) and environment. The application we run is Zend Framework-based and currently handles between 150,000 and 200,000 visitors per day.

Why switch at all?

In January of this year (2009), we started investigating the 2.2 branch of the Apache webserver. Because we used Apache 1.3 for forever, we never had the need to upgrade to Apache 2.0, or 2.2. After all, you're probably familiar with the don't fix it, if it's not broken-approach.

Late last year we ran into a couple (maybe) rather FreeBSD-specific issues with PHP and its opcode cache APC. I am by no means an expert on the entire situation, but from reading mailing lists and investigating on the server, this seemed to be expected behavior — in a nutshell: Apache 1.3 and a large opcode cache on a newer versions of FreeBSD (7) were bound to fail with larger amounts of traffic.

We tried bumping up a few settings (pv entries), but we just ran into the same issue again and again.

Because the architecture of Apache 2.2 and 1.3 is so different from one another (and upgrading to 2.2 was the proposed solution), I went on to explore this upgrade to Apache 2.2. And once I completed the switch to Apache 2.2, my issues went away.

So far, so good!

Performance?

On the performance side we experienced rather mediocre results.

While we benched that a static file could be read at around 300 requests per second (that is a pretty standard Apache 2.2 install, sans a couple unnecessary modules), PHP (mod_php) performed at a fraction of that, averaging between 20 and 23 requests per second.

Myth: Hardware is cheap(, developer time is not)!

Before some people yell at me for trying to optimize my web server, one needs to take the costs of scaling (to a 100 requests per seconds) into account.

One of those servers currently runs at 2,600.00 USD. The price tag adds up to an additional 10,400.00 USD in order to scale to a 100 (lousy) requests per seconds. Chances are of course, that the hardware is slightly less expensive since DELL gives great rebates — but the 8 GB of (server) RAM and the SAS disks by themselves are melting budgets away.

And on top of all hardware costs, you need add setup, maintenance and running costs (rack space, electricity) for an additional four servers — suddenly, developer time is cheap. ;-)

So what do we do? Nginx to the rescue?!