That presents a problem for performance, in that every time somebody requests a page you’re doing a lot of work to get the application to a state where it can start spitting out content – then at the end throwing away all that hard work you did. It wastes physical time and CPU cycles, not forgetting often IO and memory in the process. To resolve the issue you have to make your application persistent, which is something that PHP isn’t designed for in this context.

A while back I discovered that somebody wrote an SCGI handler in PHP – so that you can write your application in a way that you build it up and it serves requests from it’s already-running state, your HTTP server talks to your application via the SCGI class and dumps this output back to the HTTP server and handles the next request without it all being torn down. That’s useful, it’s what you want when you’re serving huge numbers of requests in short spaces of my time. The problem is this isn’t a complete answer to the issue.

Firstly the code can only handle 1 request at a time. If a concurrent request comes in it’ll get queued by the HTTP server until the previous request has finished. This is easy enough to resolve – if your HTTP server supports it you can just spawn multiple instances and make it round-robin the backends. Another problem is these different processes don’t know about each other, they’re completely dumb to the fact that there are more versions of themselves running – they can’t share data with their siblings, and if you want to have a process to watch over them and make sure everything is fine you need to write that code separately. Then you get even more problems if your traffic gets to the point where it’s too much for the number of processes you have spawned; you need to manually increase the number of processes.

I decided I needed to come up with a solution to the problem.

First on my agenda was to ensure it spoke a language that most if not all HTTP servers understand. SCGI is pretty well supported, but not by everything. FCGI uses a complex binary communications protocol, which is a good protocol and it’s well supported – the problem is when you’re attacking a problem like this you have no idea if in the end your solution is going to improve things at all – so it’s potentially a complete waste of time trying to implement a protocol if the project fails.

I settled with making the server code support HTTP, which aside from the fact it’s well supported, has other fringe benefits. Firstly you can point a browser at the application and test the code directly with no HTTPD needed, which creates all sorts of opportunities for doing fun things when debugging, not least because you can find out if your problem is caused by your code or the HTTP server. You can also stick hardware load balancers in between your frontend HTTP server and backend slave application servers if you need that kind of capacity. HTTP load balancers are easy to get hold of. You can even put squid between the app server backend(s) and the frontend HTTP server if you need to without making any changes to your code if you need to. Now bear in mind this is was never intended to be exposed to browsers directly, just you can because it speaks HTTP 1.1 – but it’s not the idea. This is not a HTTP server in it’s own right, not even close., it isn’t intended to be used this way. This is not Nanoweb.

The next step is was to resolve the 1 connection at a time issue. Unfortunately PHP doesn’t support threads in any kind of way, shape or form. It’s not the end of the world, but despite there being a PECL extension covering threads this isn’t going to work, it hasn’t been updated in years – and even when it was updated it never gone finished, which is a huge shame. Hopefully one day somebody recovers that extension because it has huge potential outside the traditional “PHP does this and only this” worldview.

The only opportunity for doing this stuff in PHP is to use pcntl_fork(), so I hacked in some forking code. Experience teaches me that it’s not sensible to fork our server on every request – you have to fork enough children to handle your load up-front. What I was left with after a few hours was a HTTP server class that is extended extend by your application class, in a similar way to the application server I found previously – you write a constructor that builds up stuff you always need, maybe a template engine, read in some data files, connect to a DB and whatever, then it returns to the server class which forks the process into a bunch of children. When a request comes in i hits one of the children which processes the HTTP headers and body (if it’s a POST), which in turn passes the request off to your code.

After bashing it with ab it was clearly very fast, stable and working well. The result was a fully-functioning web application (a rebuild of paste2.org) spitting out it’s home page in about 0.0004s on my crappy local development server. For the sake of unscientific comparison, the ‘same’ code on paste2′s production server manages to spit out the same page in about 0.01s. That’s a pretty major time improvement, on significantly worse hardware.

It has a few issues still else I’d be putting the code up for people to look at – they’re all solvable though with a bit of time which I don’t really have right now. The first is some of the code is a mess as it is. The second one is if MySQL (or more accurately, I’m using PDO right now, hence whatever you use) goes away the code isn’t aware and tries to keep banging away at the old connection/prepared statement – but that’s going to be easy to resolve. The next issue is I haven’t added any kind of communication between processes yet but that’s just a matter of getting to it, and the code doesn’t need it – it will just add more reasons to use it. Basically right now it’s not even as cool as it could be.

Another problem is that no opcode cacher for PHP supports CLI as far as I can see, not because of technical difficulties but that they, I guess, have been completely useless in the past. The reason why this would be useful is that some template engines (including mine) repeatedly try to include the same file which it seems isn’t cached anywhere. That could be speeded up by an opcode cacher. I could use the CGI SAPI or patch XCache and give it a try, and then see what happens. [Update: I tried this with APC in CGI SAPI instead of CLI and it does improve things, but with the nature of the beast milage may vary].

The last issue I can think of is that I haven’t written in a way yet for the code to monitor itself and spawn new children when it gets clogged up or kill off children when it has too many. It does spawn new children when another dies though, that is to say it ensures there’s always x children spawned.

Because the app is persistent there’s some other fringe benefits that one might not usually think about.

Around the time I was hacking this together, in ##php on Freenode, Rasmus was complaining about how there’s no cache for prepared statements in MySQL. A few hours later it occurred to me that because what I’ve been doing is persistent across requests and that it holds open connections to the database server if you make your app work that way (and you want it to work that way) it’d be possible to implement something resembling a prepared statement ‘cache’. I should say before I get slapped around for what follows – I know what I’m about to describe isn’t actually a cache but it’s the next-best thing.

I pulled out the application-specific PDO code from my test application (the paste2.org rebuild), and moved it to the main app server parent class. Then I added two methods, one creates a prepared statement from a string and an identifier string (whatever you like as long as it works as a PHP array key) and stores it, the other returns a reference to the ‘named’ prepared statement. Essentially you can now add prepared statements in your app’s constructor (or wherever, realistically) and reuse them time-after-time-after-time.