So I got to thinking. There are some good caching reverse proxies out there, maybe it’s time to check one out for beeets. Not that we get a ton of traffic or we really need one, but hey what if we get digged or something? Anyway, the setup now is not really what I call simple. HAproxy sits in front of NginX, which serves static content and sends PHP requests back to PHP-FPM. That’s three steps to load a fucking page. Most sites use apache + mod_php (one step)! But I like to tinker, and I like to see requests/second double when I’m running ab on beeets.

So, I’d like to try something like Varnish (sorry, Squid) but that’s adding one more step in between my requests and my content. Sure it would add a great speed boost, but it’s another layer of complexity. Plus it’s a whole nother service to ramp up on, which is fun but these days my time is limited. I did some research and found what I was looking for.

NginX has made me cream my pants every time I log onto the server since the day I installed it. It’s fast, stable, fast, and amazing. Wow, I love it. Now I read that NginX can cache FastCGI requests based on response caching headers. So I set it up, modified the beeets api to send back some Cache-Control junk, and voilà…a %2800 speed boost on some of the more complicated functions in the API.

Here’s the config I used:

# in http {}
fastcgi_cache_path /srv/tmp/cache/fastcgi_cache levels=1:2
                           keys_zone=php:16m
                           inactive=5m max_size=500m;

# after our normal fastcgi_* stuff in server {}
fastcgi_cache php;
fastcgi_cache_key $request_uri$request_body;
fastcgi_cache_valid any 1s;
fastcgi_pass_header Set-Cookie;
fastcgi_buffers 64 4k;

So we’re giving it a 500mb cache. It says that any valid cache is saved for 1 second, but this gets overriden with the Cache-Control headers sent by PHP. I’m using $request_body in the cache key because in our API, the actual request is sent through like:

GET /events/tags/1 HTTP/1.1
Host: ...

{"page":1,"per_page":10}

The params are sent through the HTTP body even in a GET. Why? I spent a good amount of time trying to get the API to accept the params through the query string, but decided that adding $request_body to one line in an NginX config was easier that re-working the structure of the API. So far so good.

That’s FastCGI acting as a reverse proxy cache. Ideally in our setup, HAproxy would be replaced by a reverse proxy cache like Varnish, and NginX would just stupidly forward requests to PHP like it was earlier today…but I like HAproxy. Having a health-checking load-balancer on every web server affords some interesting failover opportunities.

Anyway, hope this helps someone. NginX can be a caching reverse proxy. Maybe not the best, but sometimes, just sometimes,  simple > faster.

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?

So tonight I helped a client set up PHP5 on IIS 7 using MSSQL 2005. These things always work great in theory but judging my my use of the word “theory” in italics, you can probably guess that things weren’t so smooth in practice.

The client was smart enough to get FastCGI working through IIS…something I would have probably rolled over on. From then on, it was an upward battle getting a simple PHP prototype project going.

In the later versions of PHP 5, it would seem that all mssql_* functions have…been… removed? There is an ntwdblib.dll that needs to be replaced to play nicely with mssql 2005…but it doesn’t exist in the latest releases. How strange. I ended up reverting to 5.2.5, making me a not-so-bleeding-edge pushover :’(. It’s cool though.

Then MSSQL doesn’t accept normal logins, only windows ones, and it’s bloomin’ impossible finding out how to change that.

One thing Microsoft seems to have actually done right is release a rewrite module (much like mod_rewrite) that you don’t have to frickin’ pay for, which is nice. On a side note, I really hated Windows Server 2008. It’s like Vista in every way, except that the design is slightly different, somewhat. Sorry, MS, but get your shit together plz, kkthxbai.

Anyway, we got everything going. What a pain in the ass though!

If you’re wondering, I’m more of a Unix guy ;). And yes, I have used a computer before.