Let me explain the background first.  When you run PHP apps using IIS, you’re much better off using IIS’s native CGI support (slow, but rock-solid as of Windows Server 2003 SP1) or the new FastCGI support that was released last year or the year before (faster, but I haven’t tested it personally under serious stress, as I’ve managed to move back to working exclusively on Linux this year).  I’ve tried PHP via IIS’s ISAPI interface, but as that requires running PHP in a threaded environment, I’ve never had any luck in getting it working in a stable manner over the years.  Besides, iirc, both Microsoft and Zend recommend running PHP using FastCGI on IIS anyways.

Running PHP via CGI and FastCGI means that IIS has to do the Windows equivalent of fork()ing off PHP processes to do the actual PHP bit.  If your box has too many PHP processes running, the box will start to swap.  Once a webserver starts swapping, you’ve no chance in hell of keeping up with all the incoming requests, and your websites on that particular webserver become unavailable in a matter of moments.  Restarting IIS will clear off all the PHP processes, but if demand remains the same, the webserver will start swapping again very soon and you’re back to square one - your websites back to being unavailable to the outside world.

With Apache and mpm-prefork, mpm-peruser or mpm-itk, you can adjust Apache’s settings to make sure that your server never swaps.  With Apache and PHP/FastCGI, you can do this too by adjusting the number of FastCGI processes created.  (Although, atm, I don’t recommend using Apache + PHP/FastCGI in production environments).

But how, exactly, do you do this with IIS and PHP/CGI or PHP/FastCGI?  The answer can be found in the IIS 7 documentation.  It looks like you can limit the number of FastCGI instances per application pool (IIS best practice is to setup a separate application pool per website.  IIS’s architecture is nothing like Apache).  That’s fine for servers running just the one website, but is there a way to set a similar limit that applies across all application pools?  It would be great if there was.  And I’m not sure that there’s a way to do this with CGI, if you have problems with FastCGI crashing.

Love it or hate it, Windows Server is the right choice for many firms, and the better PHP runs in a Windows Server production environment, the more opportunities there are for firms and individuals that create PHP apps in the future.

Share This

Who are we?  Gradwell is a rapidly-growing ISP who focuses on broadband, email, web hosting and VoIP solutions for the UK SME market.  We are a pioneer in VoIP, and are the leading VoIP provider for UK business.  We also do fun things like Twittex, which I talked about recently at the PHPNW 08 conference.

Share This

I was there to talk about our experience at Gradwell with building our Twittex service in just seven days.  Videos of all the talks will be available from PHPNW once the editing has been finished, but if you can’t wait, my slides are now available.  A big thank you to everyone who provided feedback on the talk.  If you haven’t done so yet, I’d love to hear what you thought about the talk.

It takes surgery to separate me from a camera, and the PHPNW 08 weekend was no exception.  This was my first weekend with my new Panasonic DMC-LX 3 (which I bought on the journey up to the conference).  I had great fun putting the camera through its paces, and you can see the results up on Flickr.

Share This

As well as being there to talk about how we built Twittex in 7 days, I’m very interested in meeting up with folks in the UK who are freelance web developers.  I want to know more about what you want from a web hosting solution, especially what you’d like to see but can’t find anywhere in the UK atm.  If that sounds interesting to you, drop me a line before the conference, and we’ll arrange to meet up during the Friday or Saturday evening socials.

And I’m also interested in talking to anyone who’s going to PHPNW08 who’s interested in building apps for VoIP too.

Share This

What would you add to this list?

• Arrange with on-line friends to meet up either the night before or before the presentations start on the day.
• Look for social groups (e.g. PHP Women) you can join before the conference, to see if anyone like-minded is going.
• If the conference has more than one presentation going on at once (== multiple tracks), work out in advance which presentations you’d like to go and see.  You can always change your mind afterwards
• Bring a laptop - a lot of the conversation at the conference happens online (such as on Twitter).
• Bring a mobile broadband card with you too (do you have mobile broadband outside the UK?), as conference wireless systems can be incredibly unreliable.
• Be yourself, but don’t bullshit - the folks you’re trying to impress could be prospective customers, work colleagues or employers.
• Stay for the after-conference drinks & food, where you can socialise and network.

Share This

I’ve already written about a number of solutions that work, but one option I’ve been asked time and time again to look at is using PHP + FastCGI. The belief is that using FastCGI will overcome the performance issues of Apache’s suexec or mod_suphp, because FastCGI processes persist between page views.

But before we can look at performance, the first question is: how exactly do we get PHP and FastCGI running as different users on the one web server in the first place?

Installing And Configuring mod_fcgid for Apache

Stock Apache does not ship with built-in support for FastCGI. You need to download and install a third-party module. There are two choices - the original mod_fastcgi, and the more recent mod_fcgid, which I’ll look at in this article.  Before we start, make sure that you have built and configured Apache to use suexec.  We will reuse suexec to ensure that our FastCGI PHP processes run as different users.

Most Linux distributions already include a package for mod_fcgid; you should be able to install it using your distro’s package manage.  The version I’ve tested for this article is mod_fcgid 2.2 running on Seed Linux (a Gentoo-based distro).

After installing mod_fcgid, make sure that you edit your Apache config files, and comment out any lines that load mod_php.  They will look like this:

LoadModule php5_module modules/libphp5.so

Then, add the following lines to your virtual host.

SuexecUserGroup myuser mygroup

<Directory /var/www/localhost/htdocs>
AddHandler fcgid-script .php
Options ExecCGI
Allow from all
FCGIWrapper /var/www/localhost/cgi-bin/php.fcgi .php
</Directory>

Replace “myuser” with the user who owns the website, and replace “mygroup” with the group that the user belongs to.  This sets the privileges that PHP will run as when this website is visited.

Because suexec is understandably paranoid about what CGI programs it will run for you, to make mod_fcgid work in a shared hosting environment, we need to create a FastCGI wrapper script owned by the same user that owns the website:

#!/bin/bash
PHPRC=/etc/php/apache2-php5
export PHPRC
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
PHP_FGCI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS
exec /usr/lib/php5/bin/php-cgi

Each website needs its own copy of the script.  Place this script in the website’s dedicated cgi-bin directory.  This should be a directory that you control to make sure that malicious scripts cannot be uploaded to take advantage of suexec.  Make sure that the script is owned by the user and group who owns the website, otherwise suexec will refuse to run the script, and you’ll spend quite a bit of time scratching your head wondering what the problem is!

The FastCGI wrapper script gives us an opportunity to set limits on how PHP works as a FastCGI process.  We can tell it how many FastCGI scripts are allowed to run (to make sure one website doesn’t use up all of the web server’s free capacity), and also how many HTTP requests each FastCGI process should handle before terminating (to limit the impact of memory leaks).

At this point, you can restart Apache, and you should find that your websites are now using suexec + FastCGI to run as separate users.

Making Apache Go Even Faster

One of the major benefits of using Apache 2.2 over Apache 1.3 is the ability to switch how Apache works at the fundamental level. Apache MPMs (multi-processing modules) can emulate Apache 1.3’s behaviour (mpm-prefork) … but it can also provide new options.  By default, most (if not all) Linux distributions install Apache 2.2 built with mpm-prefork, but by switching to another MPM, can we make our websites go even faster?

If you are using suexec + mod_fcgid on Linux, there are two MPMs available to you that have the potential to boost performance further: mpm-worker and mpm-event.  Both MPMs turn Apache into a multi-threaded server.  On Linux systems, it is usually much quicker to create new threads than it is to create new processes.  The downside is that software has to be specially written to work correctly in a multi-threaded application (known as being thread-safe).  mod_php doesn’t work reliably with mpm-worker and mpm-event, because it reuses a lot of third-party code that may or may not be thread-safe.  But because we’re running PHP in a separate FastCGI process, we can safely turn Apache into a multi-threaded server.

Some Benchmarks

To benchmark PHP + FastCGI + suexec, I used Apache’s ab benchmark to load a simple phpinfo() page 1,000 times. I ran the benchmark five times, and averaged the results. To compare the results, I repeated the tests against mpm-worker, mpm-event, and mpm-prefork both with and without mod_php.

• mpm-worker + mod_fcgid + PHP/FastCGI + suexec: 7.36 seconds, 0.2% failure rate
• mpm-event + mod_fcgid + PHP/FastCGI + suexec: 7.75 seconds, 0.2 % failure rate
• mpm-prefork + mod_fcgid + PHP/FastCGI + suexec: 7.92 seconds, 0.2% failure rate
• mpm-prefork + mod_fastcgi + PHP/FastCGI + suexec: 8.52 seconds, 0.2% failure rate
• mpm-prefork + mod_php: 7.38 seconds, 0% failure rate

Other Considerations

The performance is good, especially if you switch Apache MPMs.  These benchmarks are extremely simplistic, and what they don’t show is that switching to mpm-worker and mpm-event will probably speed up your websites even further, because these Apache MPMs handle downloading images more efficiently than mpm-prefork can.  You may also be able to scale your websites better before having to upgrade your servers or add additional ones, especially if you use a bytecode cache such as APC or xcache.

But what are the downsides?

• As with straight suexec, you can’t use HTTP authentication in your application.  Hardly any apps rely on this functionality any more (probably because so many shared hosting servers use suexec).
• Your server may require extra RAM to cope with the number of FastCGI processes running simultaneously.  You may need to switch to a 32-bit Linux kernel that supports PAE or to a 64-bit Linux distro.
• Apache + PHP/FastCGI is not 100% reliable in my testing.

Conclusions

It is possible to combine PHP, FastCGI and suexec to produce a solution that secures a shared hosting server and at the same time provides good performance compared to the alternatives. If you’re prepared to compile Apache from source and switch MPMs, you can squeeze even more performance from this combination, and perhaps even out-perform the venerable mod_php.

Unfortunately, my experience was that the PHP + FastCGI combination cannot be trusted to serve pages 100% of the time. The average failure rate was 2 requests per 1000, and the failure rate was consistent no matter which Apache MPM was used, which Apache FastCGI module was used, and how many thousands of requests I used in my testing.  At the time of writing, I haven’t tracked down the cause of this failure, and it may not appear in your own environment, but none of the previous solutions I’ve looked at in this series have displayed this problem, so it’s something to think about before chosing PHP + FastCGI to serve your websites.  I’m hoping to find time in the future to get to the bottom of this problem, if no-one gets there first.

As a result, I can’t recommend using PHP/FastCGI + suexec at this time.  My current recommendation is mpm-itk, which has successfully served millions of page hits for me in production over the last few months.

References

This article was made possible by information already on the internet:

• http://interworx.com/forums/showthread.php?p=8327
• http://ckdake.com/projects/documentation/php_security

This article is part of The Web Platform, an on-going series of blog posts about the environment that you need to create and nurture to run your web-based application in. If you have any topics that you’d like to see covered in future articles, please leave them in the comments on this page.

Share This

Share This

The last time I spoke at a conference was on Marco’s first php|cruise back in 2004, where we enjoyed a great view from the bar.  There wasn’t really a UK PHP scene back then, so I’m looking forward to seeing how that’s changed in the last four years.  We built twittex in-house, but we also outsource PHP development, and I’m very interested in meeting up with folks offering PHP and symfony development who are interested in VoIP (we’re the UK’s third largest VoIP provider) and social apps, and also with anyone interested in integrating VoIP into their apps too.

See you in Manchester in November!

Share This

Six days later, thanks to the power of symfony, PHP, mysql and q4m, we’ve built and launched a replacement service called twittex.com.  This is a very simple-to-use prepay service that allows you to follow the friends of your choice on the mobile phone of your choice via SMS, and it’s now live

Share This

Where are the benchmarks for phar?

Share This