Is mod_php falling out of favor with hosting providers?

Recently I received a comment on a post about modperlite alleging that modphp, an Apache module mod_perlite is modeled after, is falling out of favor with hosting providers. That is quite an allegation - one that I initially shrugged off because it seemed preposterous to me. I mean just consider for a moment all of the incredibly popular applications including WordPress, Drupal, PostNuke, phpBB, Mediawiki and many more too numerous to list here let alone count that all rely on PHP exclusively.

Not wanting to completely discount this comment I decided to consult a close acquaintance of mine that works with one of the most popular hosting providers on the Internet. In working with him on a number of projects I have come to respect him on a number of levels, but especially for his knowledge of operations and system architecture. He spends a great deal of his time every day trying to maintain systems running software he didn't write or install on machines run by users he has little or no control over. He is an expert in cleaning up after others. So I asked him if he had an opinion about this statement.

What I learned through our email dialog was enlightening, and I wanted to share it with a larger audience. He permitted me to republish parts of our correspondence, but asked to remain anonymous. (Editorial note: I have taken some of his text and elaborated as best that I could in order to provide a more complete overview of this issue.)

This is a rather multifaceted issue, but to summarize I'd venture that mass virtual hosting on the whole is trending away from mod_php/mod_perl.

He proceeded to back this claim up:

  • Real file I/O is impossible or insecure - it is difficult to harden a mod_perl/mod_php application because these Apache modules only run in the permissions context of the web server's user. Software that helps resolve this issue, like suPHP, which allows a script to run in the permissions context of the script's owner, negate the performance benefits of the underlying mod_perl/mod_php module.

  • One of the more viable solutions to this permissions dilemma, an Apache module called mpm_perchild, died on the vine years ago. "This was the Apache 2+ intended answer for the security problem and was supposed to (correctly, IMO, given Apache's architecture) have each request thread out based on file ownership, sort of a rolled in suexec."

  • "There is growing adoption of code frameworks (rails, django, catalyst, etc etc) that just don't play with mod_php/perl. Building an effective cgi/fastcgi architecture covers bases better."

  • "There is a growing adoption of very powerful web servers like lighttpd and nginx whose only interface is cgi/fastcgi. To many developers today Apache really is an anachronism."

  • "Another side effect of cgi/fastcgi that I neglected to mention is that it is much more apparent which users' code/processes are monopolizing resources" thereby making it easier for hosting providers to monitor, enforce resource utilization policies and recover from systems under load.

Then y friend also responded to this comment:

@saj - really? You think mod_php is falling out of favor? That is quite a statement... one that I can't imagine is true. PHP is one of the most ubiquitous web scripting languages, second only to Perl. A cannot imagine hosts degrading their support for this language.

With this response:

I think this is the most important misconception to dispel. In an Apache vhosted setup, modphp *is* degraded support. Settings like safemode are generally implemented and users don't have access to edit their own php.ini, relying on .htaccess hackery to eke out the limited php settings customization available.

He concluded, "there is a ton more to the issue and these points really don't do it full justice."

Now lets be real, I don't think my friend is saying that hosting providers will drop support for PHP, not in the foreseeable future, but if hosting providers tend not to prefer mod_perl and mod_php based applications what will this mean for all us developing on top of these languages and deployment platforms?

And ask yourself, when you write a web based application, are you thinking about the company that is going to be hosting your application for your customers/users? And what are you doing for them to make their lives easier?

Recommended Entries

5 Comments

I think you misunderstood your friend. He was saying that mod_php was falling out of favour, not PHP itself. PHP can be run using fastcgi (which he mentions as gaining popularity) and doing so provides a number of benefits in terms of resource management and per-user security. From a PHP developer's point of view it really doesn't make any difference if PHP is served up using mod_php or fastcgi - in fact, I'd bet most users of shared hosting wouldn't notice either way.

@Simon - I totally grok the difference. But PHP as a language has the challenge of being tied in some fundamental way to its run time environment. While PHP can be invoked as a CGI I am willing to bet you would be hard pressed to find many people running PHP that way. That is primarily because PHP's greatest strength is how easy it is to install and find supported by virtually any hosting provider. You can just drop in a PHP script and it works, with precious few quirks.

The idea of running PHP as a fastcgi though brings us back full circle to what was motivating the development of mod_perlite... FastCGI is actually hard to install, and poorly supported. I am a reasonably intelligent and technical guy capable of setting up machines, deploying applications, compiling kernels and the like, but I have often been baffled as to why a seemingly simply FastCGI installation simply refuses to work.

FastCGI may indeed be the future, that I won't debate... but the FastCGI options on the market today have a lot of problems - making its adoption difficult at best.

FastCGI is indeed difficult to configure, but not when using PHP thanks to php-cgi built-in fcgi daemon. There is no need to build and use any complex dispatchers. Just assign a port or domain socket, run php-cgi (fcgi) in background (&) and everything works with Apache, Nginx, Lighttpd or any other server that supports FastCGI.

Perl fcgi is a different story though...

I realize this is a rather old post, but I thought I'd add that a lot of these problems can be mitigated running the apache2-mpm-itk MPM. Certainly FastCGI gives you more control over resource usage per user, but it's also more complex to set up generally than adding an AssignUserID directive to each VirtualHost container.

I am looking for a LAMP shared hosting provider that uses modPHP (and has a good reputation). Verio/etc. all seem to be CGI. Any suggestions for a US based shared hosting provider doing LAMP and modPHP?

Thanks.

Leave a comment

what will you say?


Recent Comments

  • I am looking for a LAMP shared hosting provider that uses modPHP (and has a good reputation). Verio/etc. all seem to be CGI. Any suggestions for a US based shared hosting provider doing LAMP and modPHP? Thanks. ...

  • I realize this is a rather old post, but I thought I'd add that a lot of these problems can be mitigated running the apache2-mpm-itk MPM. Certainly FastCGI gives you more control over resource usage per user, but it's a...

  • FastCGI is indeed difficult to configure, but not when using PHP thanks to php-cgi built-in fcgi daemon. There is no need to build and use any complex dispatchers. Just assign a port or domain socket, run php-cgi (fcgi) ...

  • @Simon - I totally grok the difference. But PHP as a language has the challenge of being tied in some fundamental way to its run time environment. While PHP can be invoked as a CGI I am willing to bet you would be hard p...

  • I think you misunderstood your friend. He was saying that mod_php was falling out of favour, not PHP itself. PHP can be run using fastcgi (which he mentions as gaining popularity) and doing so provides a number of benefi...

Close