So As some of you know, a while ago I switched from Apache to lighttpd…I mean, youtube uses it right? No doubt a highly modified version. Not long after I get it set up just perfectly, I started reading ALL the horror stories about memory leaks.

Now granted I didn’t run into any memory leaks, but I’m not going to bet for something that is consistently failing all around me. Then I heard of Nginx. Keep in mind this all happened at least a month ago…I just haven’t had time to blog at all. Anyway, it’s supposedly faster than lighty, it’s actually stable and doesn’t need rebooting every night, and it’s russian.

So being the tinkerer at hear that I am, I decided to install it on the beeets.com server. Well, the syntax in in the config file was a bit of a learning curve. It’s sort of like C but not as friendly. A space in the wrong place will make it fail. Needless to say, I got it all configured though. FastCGI, PHP, URL rewriting, client-side caching, and if I need it later on, a kickass reverse proxy.

So I guess this is me saying a few months later than nginx totally kicks ass. It benchmarks so much better than Apache, and it’s russian.

I think the next think I’ll be tinkering with (fucking up) will be MySQL replication. From what I read, it’s better than clustering for a few reasons. You can do things with replication you can’t do with a cluster. The problem is there will definitely be some gnarly code tweaks because nothing supports it by default, at least not that I know of. Oh yeah, plus there’s like, no documentation on writing a PHP app for a replicated database. I know, read from the slave, write to the master, but if you write to the master and immediately need to read a generated value (last id) then you have to read from the master since you can’t rely on the slaves to be kept instantly up to date. That’s a fun code change.

So after hours of searching and tweaking, I finally got the answer I never wanted: it’s not possible to have apache serve mod_fastcgi requests through it’s own reverse proxy (ie load-balance mod_fastcgi). I know this is incorrect. But it had taken me so long and wasted so much time getting to the point where I was almost as clueless as when I started, that I took drastic action.

I installed lighttpd. I already had the FastCGI setup running, not to mention I got a new Linode for testing remote PHP. The only problem was that I couldn’t load balance between my slack box (web server) and my new linode (debian app server). BTW I chose Debian because the image was smaller and from what I know, it’s essentially the same as Slack. I really haven’t had ANY problems moving to it yet, and let’s face it, Deb is a lot more standard. Installing PHP was a bitch, but that’s what apt-get is for (no, I compiled PHP…but I’ll be damned if I’m going to hand compile all the stupid dependencies).

Anyway, within 20 minutes, lighttpd had PHP running through FastCGI load balanced between two servers. Needless to say, I fell in love. Not to mention all the information I was inundated with along the way about how small and lean lighttpd is swayed this choice a little.

So as far as I know, beeets is running great on both of its “new” servers and loving it.

There was a bit of trouble getting used to the new URL rewriting scheme, but generally instead of doing apache’s

RewriteCond blahblah !-f

You can just do url-rewrite(‘(images|css|js)’ => ‘$0′)

(this is a horrible oversimplification, but you get the idea)…you write the URLs you DON’T want to be rewritten to $0. Works wonders.

All that’s left is some cache-control headers (I’m crazy about them, if you can’t tell yet), and some speed testing. I’m excited to see if lighttpd is actually faster than apache under ab.

Next up, Capistrano.

Wow. You’d think it would be easy. In fact, it should have been. Compile a module, load it from apache. Recompile PHP with –enable-fastcgi…oh wait, I already had it in there (always thinking ahead!!). Change some apache settings.

Right? Yeah, right. It took two days. I can’t even really remember why. The biggest problem was that running make && make install in the mod_fastcgi source was NOT yielding a ‘mod_fastcgi.so’ as the documentation PROMISED! In fact, it installed mod_fastcgi.la instead, a highly useless file.

So how did the master get out of this bind? Beats me, try asking him. As for me, I had to run ‘ld -Bshareable *.o -o mod_fastcgi.so’ which is mentioned in some document from a long time ago in a galaxy far, far away.

Let me interject and say that the information on the FastCGI website is “not very well documented.”

Day 2. I figured, what’s the point of FastCGI if it’s not set up to connect to a remote App server? Maybe I don’t HAVE an external server set up, but we can pretend. Well that’s another nightmare. There’s a good external FastCGI guide written about it, and guess what it worked. Not really a nightmare at all, come to think of it. Quite pleasant.

All in all, shouldn’t have taken 2 days =P (I’m a tinkerer)…but fuck it, I have FastCGI now, ready to connect to all those App servers I have churning away in the background (one day).

In all the excitement, I also compiled and installed the apache worker-MPM. A few tests with ab didn’t really show any noticeable difference. But threads are cool, right?

Next up: figure out how to configure Apache to pass all requests ending in .php (whether the file exists on the web server or not) to our “app” server. Is this possible?