Is mod_php falling out of favor with hosting providers?Posted: November 24, 2007
Recently I received a [comment](http://www.majordojo.com/2007/11/how-to-fix-cgi.php#comment-72453) on a post about mod_perlite alleging that mod_php, an Apache module [mod_perlite](http://www.majordojo.com/2007/11/how-to-fix-cgi.php) is modeled after, is falling out of favor with hosting providers. That is quite an allegation – one that I initially [shrugged off](http://www.majordojo.com/2007/11/how-to-fix-cgi.php#comment-72485) because it seemed preposterous to me. I mean just consider for a moment all of the incredibly popular applications including [WordPress](http://www.wordpress.org/), [Drupal](http://www.drupal.org), [PostNuke](http://www.postnuke.com/), [phpBB](http://www.phpbb.com/), [Mediawiki](http://www.mediawiki.org/) 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](http://www.lighttpd.net/) and [nginx](http://nginx.net/) 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](http://www.majordojo.com/2007/11/how-to-fix-cgi.php#comment-72485):
> @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, mod_php *is* degraded support. Settings like safe_mode 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?