till's blog

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!

Frequently, you do client work and if you are fortunate enough, you can setup a development environment on your own server or your laptop (or whatever), tinker with the files, and templates, and so on — until it's all done.

And whenever you are done, it's time to move files.

Sounds easy? It sort of is!

Checklist

Here's a small check list of things to keep in mind when you move an installation.

1. You may need to fix up the configuration file in order to adjust all database related settings. It's located in app/etc/local.xml.

2. Certain directories will need to be made writable. Writable in this case means that the webserver has to be able to write into it. Since most of the standard PHP setups are with mod_php, this will be the user www, apache or www-run (in most cases). If you (or your provider) runs php-cgi, chances are that this is not necessary.

   You may have to ask an administrator to set this up. If the administrator is not available, you can always chmod 777 these, but for obvious reasons this may be risky in a shared environment.

   The following is a list of directories (and contents) which need to be made writable:

   • app/etc/
   • var/
   • media/

   And in case you want to use MagentoConnect, there are additional directories to make writable. Please see this blog post for more info.

3. URLs, URLs, URLs. You were working on localhost all this time and now you think you can move it over just like that? Wrong!!! ;-) But all you need to do is edit the following keys in the core_config_data table:

   • web/unsecure/base_url
   • web/secure/base_url

That's all folks!

If you have any additions, please leave a comment!

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

Thanks to Wesley, we recently managed to update CouchDB's FreeBSD port to the official 0.9.0 release.

My current TODO for the port includes:

• a super-cool rc-script (currently, there is none)
• automatic user setup/creation (couchdb)
• patching of the install/source to use BSD-style directories for the database (e.g. /var/db/couchdb).

In regard to the the rc-script, I continued on a work in progress and committed an idea on Github. This work in process (couchdb) works out of the box. Just download the file, put it in /usr/local/etc/rc.d/, chmod +x couchdb and done. I also updated the CouchDB wiki page explaining how CouchDB on FreeBSD is setup (e.g. the options of the rc-script) and updated the instructions on user creation — something that I plan to roll into the couchdb port ASAP.

But before I continue on the port, I'd like to ask for feedback from people (Probably, you!) who use CouchDB on FreeBSD. For example, are you happy with the current options, or do you need a different set, etc.. If this work in progress is what you need, then that's valuable feedback as well.

Thanks!

I bought a Drobo for myself about seven months ago and I couldn't be any happier. My files are backed up on a RAID system, I still got plenty of space to waste. My world is OK.

Some friends of mine recently bought one of the new Drobo units with a DroboShare. The DroboShare costs $200 (USD) and is a glorified Linux server which exports your Drobo using Samba to all clients on the network.

My friends are using Windows and MacOSX to connect so after some intial problems where they were running FAT32 and the Drobo decided to go unlabeled, we decided to format the unit and use HFS+ instead.

Unlabeled?

I googled this and to my surprise there are no information available - Data Robotics keeps it all pretty well hidden behind case numbers on their ticketing system. It would be nice if they provided more details why a Drobo unit would end up in unlabeled state.

HFS, or what's your flavour?

Our reasons to select HFS+ are:

• It's a modern filesystem (vs. FAT32) with journaling.
• If all fails, you can hook it up to the Mac and use DiskWarrior to recover the volume.

If you are not using a Mac and keep in a Windows-only environment, it makes more sense to select NTFS, in a Linux-only environment you are save with ext3. I would select a filesystem which still allows you to hook up the Drobo to any of your clients in order to be able to easily recover the volumes in case they decide to stop working.

Network write issues

When we setup the Drobo we tried to copy 2 GB from various clients to it. What took between 7-9 minutes on most clients, was estimated with 30 hours on Tiger. ;-)

To rule out an issue with the Drobo, we briefly tested the performance from various systems. The candidates included Windows XP, Windows Vista, MacOSX 10.5.4 (Leopard), Ubuntu 8.10 and MacOSX 10.4.11 (Tiger). The Drobo performed well on all systems -- except for Tiger.

Researching the network issue on Google, I found various people who reported all kind of network issue with 10.4.11 and since there are other random crashes on the same workstation we pronounced the Drobo to work and perform. The workstation is subject to a system overhaul next week.

Ubuntu

Setting up the Drobo on Ubuntu is pretty easy -- point taken, there is no Drobo Dashboard and the drobo-utils only supported units which are connected via USB or Firewire directly to the workstation.

To setup the share you could samba mount \\DroboShare\DROBO and provide the same credentials you use on Windows/Mac when the Drobo Dashboard prompts you for a login to the DroboShare. An alternative with GUI is to use Places > Connect To Server.

The DroboShare itself exposes itself on the network and registers itself as (well) DroboShare in DNS/WINS (netbios?) -- if you decide to use its IP to setup shares and so on, make sure to assign a static IP to the DroboShare (MAC-Address is on the bottom side of it) so the IP doesn't change when you restart your router or the lease expires.

Hope this helps!