till's blog

I updated my mother's Mac Mini from Tiger to Snow Leopard last night and I did not enounter many issues during the one-hour-long installation (or update) process.

In advance — in order to be save than sorry — we had bought an external hard drive and did a backup of her home folder (6 GB — I wish my own backup was that size ;-)).

The one thing I ran into was that after the installation finished, I tried to reconnect to our wifi — but if failed. It wouldn't even show the network.

Since I knew that hooking up the Mini using a cable required me to move everything from her desk in one room to another room, I gave up last night and had myself a beer instead.

A solution

This morning, I briefly researched the issue on Google and found a thread on apple.com where people suggested to do the following:

• Go into System preferences > Network
• Click on Airport
• Delete the "Automatic location" profile
• Add your own
• Disable/enable Airport
• Done

Well, that almost worked for me.

I also re-added our wifi to the preferred network list and we were instantly reconnected.

Anything else?

Aside from the wifi issues almost everything migrated without issues.

This is still a pre-Intel Mac Mini. All her email, pictures and documents are in place. The only thing I need to reinstall is something called Kodak Easy Share since whatever she has installed doesn't seem to work right now.

And as a bonus, Snow Leopard feels faster even on this aging little piece of technology.

Anyway, I just thought I'd share.

So, every once in a while I find myself in need of trying out newer, maybe, not-yet-released features in PHP. For example, recently, I wanted to test RoundCube PHP6 — this is how I did it.

On a side note, the same setup would also work for testing code with previous versions of PHP.

Toolbox

I used nginx and the PHP source with a little bit of ./configure and make — for kicks!

My O.S. of choice is FreeBSD and therefor the installation steps covered are tailored to it. With a small amount of Linux/Unix-fu, anyone should make it work on another distribution regardless.

Install nginx

First off, install nginx. On FreeBSD, this should be all:

• cd /usr/ports/www/nginx-devel && make install distclean

On other systems, this maybe a:

• apt-get install nginx
• emerg nginx
• rpm -shoot-myself nginx

The next step includes the infamous spawn-fcgi which many people use to control the php-cgi processes. A lot of tutorials on the net suggest to install lighttpd because it's a part of it, but on FreeBSD, you may skip that and do the following instead:

• cd /usr/ports/www/spawn-cgi && make install distclean

Pretty cool, huh?

So once this is done, the usual tasks need to be completed — in no particular order:

• edit the nginx config and enable fastcgi in nginx (/usr/local/etc/nginx/nginx.conf)
• enable nginx itself in /etc/rc.conf (nginx_enable="YES")
• get another nifty start script (see Shell Script) to wrap spawn-cgi

... and done!

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?!

We frequently get users on #pear (@efnet) who happen to run Plesk and need help setting up PEAR. Now running any config interface is a blog entry by itself and when I say Plesk, I should also mention confixx and cpanel. And while I have a strong dislike for all them, let me focus on Plesk for now.

This is not a copy'n'paste howto, so make sure you double-check all steps involved. With little knowledge, you should be able to to apply all instructions to any other control panel, all you need is SSH access to the server.

I installed PEAR, but it's not working

The number one reason here is that even though the include_path is setup correctly, you also run with open_basedir. For pseudo security reasons, Plesk typically restricts open_basedir to your "document root", for example:

/srv/www/vhosts/domain.com/httpdocs
/srv/www/vhosts/domain.com/subdomains/test/httpdocs

(httpdocs is the document root.)

To verify the above, create a file called phpinfo.php in httpdocs, with the following content:

<?php phpinfo(); ?>

Look for include_path, it should contain something like /usr/share/php/pear and the open_basedir, which should contain this setting as well -- but doesn't.

Plesk internals

To understand the issue entirely, let's look at how plesk builds virtual hosts.

• Each domain name has its own virtualhost include file, called http.include
• The http.include is located in:

/srv/www/vhosts/domain.com/conf

• The settings (e.g. open_basedir) are set using php_admin_flag/_value which makes overriding through ini_set() or .htaccess unsuccessful.

Solutions

• The Annoying: Hack http.include and lose changes each time Plesk rebuilds your hosts (with each update). :-)
• The high road: Find and edit Plesk's default template to add your PEAR installation to the open_basedir directive, or to turn off open_basedir completely. In this, case, what you're looking for is called "domain template" in Plesk, but because I'm not a Plesk user, I don't know much about it -- feel free to correct me.
• The intermediate fix: Run your own local PEAR installation for each domain name.

Running your own PEAR installation

Running your own PEAR installation per domain name is a pretty solution, even if you managed to rid yourself of open_basedir, there are a couple strong points.

Adantages

• Dependencies, local and trackable -- vs. global (one installation per server).
• This allows you to use different versions of packages when required by the software you use/run.
• You can't really have enough PEAR. :-)

Disadvantage(s)

• More management.

Note: you may need to adjust the paths, my examples are from a Plesk install on SuSE.

Installation

This is assuming that you already installed one copy of PEAR through your system's package manager -- for example, aptitude on Debian and Ubuntu, yast on SuSE, rpm on RedHat(e) and CentOS or ports/pkg on all BSDs.

Go into your domains document root and create a pear-directory:

cd /srv/www/vhosts/domain.com/httpdocs/
mkdir my_pear
pear config-create /srv/www/vhosts/domain.com/httpdocs/my_pear .pearrc

This should create a .pearrc file in the current directory, which holds the local installations' settings.

How do we use it?

Per User

If your website user has ssh, you move the .pearrc to the users home directory, which is the directory you end up in when you login via ssh.

mv /srv/www/vhosts/domain.com/httpdocs/.pearrc /srv/www/vhosts/domain.com/

To test if the .pearrc file is being read, issue the following:

pear config-show

The screen should show paths which contain /srv/www/vhosts/domain.com.

If that is not the case, try the following:

pear -c /srv/www/vhosts/domain.com/.pearrc config-show

If it's working, continue to install the packages you need. Since this is a new installation, the first should be PEAR itself:

pear install PEAR

Or:

pear -c /srv/www/vhosts/domain.com/.pearrc install PEAR

Conclusion?

If you followed this guide, I hope it enabled you to have a different -- yet maintainable -- PEAR setup per directory. All you need is to use a different PEAR config file using the -c switch.

Further information is available on the PEAR manual.