code angry: Application gateway via very powerful Perl code

I’ve been banging my head against fastcgi. At a fundamental level, fastcgi is meant to be a CGI gateway allowing multiple simultaneous processes to run at once, to serve pages.
Ok.
nginx (and Apache, and others) can use fastcgi to run PHP code. Well, Apache can run it “natively” while the others need to run it externally.
Our website is PHP based (drupal).
So are some of our tools. And ya know, the transition to nginx has not been smooth for them. I found that nginx can communicate with fastcgi, and there are many different recipes … and most don’t work (on the net).
So here I am, with a load of PHP code I have to run.
FastCGI is a proxy at the end of the day. It runs php-cgi.
So why again, do I need FastCGI to do what I can do … far better, faster, safer?
Big issue with fastcgi is that the only way you can debug it is via tcpdump or similar packet capture. Why is this good? I want to be able to look at http requests running around. Makes debugging much easier.
Nginx does an absolutely awesome job of proxying. So why not proxy the site I want back to a gateway code that I write to run collections of PHP cgi?
Well … I did it. Less than 1 hour of coding, and the damn thing works, and is quite fast. Even have protection for site stuff in there. Its not generalized right yet. But it will be.
Here’s a snapshot of my desktop with it running:



Read morecode angry: Application gateway via very powerful Perl code

Nginx rules …

I was having lots … and I mean LOTS of trouble with apache 2.2 on the new web server. It simply refused to do vhosts no matter what I did. Debugging it was painful. I’d tried lighttpd in the past, and while I liked some aspects of it better than Apache, it still was hard … Read moreNginx rules …