Jeb Wilkins

Coding and climbing in Cumbria.

Cats and Dogs (or PHP and Rails)

I’ve been thinking a little about PHP and hosting recently. Whilst Apache with mod_php is very simple to use and incredibly popular, it does have its own sets of problems. Amongst these

  • are inefficient use of resources - every image/css/js file that gets downloaded is server by a web process with a full copy of PHP embedded in it.

  • security - all scripts run as the same user, which is whatever Apache is running as

Passenger, aka mod_rack, operates on a different mechanism - Passenger is small and runs within Apache itself, ¬†apps are spawned as a separate processes on the fly as and when needed. Apache then talks to these apps over a socket. Since they’re a separate processes, they can be run as the appropriate user avoiding security problems.

The split nature of Passenger means it also has a largely unknown feature of being able to run WSGI apps (ie Python) since they connect operate in a similar manner. So long as the app at the other end talks correctly to the socket, Passenger wont care, and Ruby’s Rack is largely a clone of WSGI from the Python world.

In many ways this is similar to Apache and FastCGI PHP but without the complexity involved in setting that up. Having set up servers with FastCGI and running PHP as the correct user I can attest that this is a non trivial setup, loosing all the deployment advantages PHP normally provides.

An interesting alternative would be to some how tie PHP to Passenger - using Passenger as a proven lightweight spawner within Apache, and having it spawn PHP processes as appropriate users on demand. The two ways to do this are either

  • writing PHP apps specifically for this system, which get loaded all at once, and then talk a Rack like protocol to Passenger through the connecting socket, clearing themselves up after each request

  • a custom PHP SAPI which listens the socket to Passenger, launches PHP scripts and waits for them to exit (much like the existing mod_php). Then feeding the output back down the socket to Passenger.

Either of these would require a new ‘app launcher’ script in Passenger to handle the initial spawning of PHP.

I think the second option is the more interesting since it would work with existing PHP scripts, and would result in PHP still operating in the normal manner. Such a SAPI is, in principle, similar to the new embedded HTTP server in PHP54 - a long running PHP process, which listens and talks on sockets. Having looked at the PHP sources this looks plausible but well outside my C skills - maybe its time I properly learnt to code C. Still its an interesting idea and I’ve not yet found anything to suggest someone is working on something similar.