If you've been involved with any sort of serious web hosting environments the term "Web Farm" will be familiar to you. This is where multiple computing environments are brought together to act as one to bolster computing power. IIS 6 brought a new feature to the table called a "Web Garden" which is a similar concept of colating computer power except this time using software on a single hardware node. A Web Garden can only be used when IIS is running in worker process isolation mode (default), and is configured on a per application pool level.

Using FastCGI with PHP on IIS is nothing new to me as I've been using the PHP community version of FastCGI which was originally written by Shane Caraveo since 2003, however rules to tweaking the performance of FastCGI on IIS have changed a little bit with the Go Live release of Microsoft's FastCGI handler last month. Historically when configuring PHP on IIS to use FastCGI with the PHP community version or the technical preview releases from Microsoft you increase the number of PHP CGI instances until you found the sweet spot for your particular environment. Well, getting the number of PHP instances right just got a lot easier with the Go Live release.

With the Go Live release of Microsoft's FastCGI handler last month I decided that it was time to put PHP 5.2.x through its paces and see just how fast I can get it to go on IIS. Following in the footsteps of Bill Staples who performed a similar test with PHP and the early release of the Microsoft FastCGI handler on IIS7, I decided to use Bill's WCAT (Web Capacity Analysis Tool) scripts and just modify the URL component for my own test. However, unlike Bill I have elected to use the Go Live release of Microsoft's FastCGI handler on IIS 6 with a mix of Zend and community versions of PHP 5.2.4. Not only that, I have also chosen not to use a web application which is written purely in PHP such as Bill did with Qdig, but have instead decided to use some popular everyday PHP web applications which use a MySQL database for data storage. To try and get a good cross section of PHP/MySQL based web applications I selected Wordpress 2.3 for blogging, Drupal 5.3 for a CMS and Gallery 2.2.3 for a photo gallery. Lets see the results.

On the Xoops.org forums you'll find many user enquiries as to how to maximize the performance of their Xoops site. A very legitimate question for a webmaster who is mindful of end user experience, and who is wanting to ensure that their site has the scalability to take on future traffic growth in its stride. The majority of the time these users will be advised to ensure that they have activated the caching system that is built into Xoops, and to a large degree this is very solid piece of advice.

However, as we'll discover in this article, maximising the use of the Xoops caching system is just the tip of the iceberg.

Those of us that have been around Xoops for a while now will know that requests for a fully featured, world class forum module that is fully intergrated into the Xoops core has been a regular, and intensely debated topic on the official Xoops forums. The original NewBB forum module that ships with all versions of Xoops 2 is undoubtedly a very slick and very quick module, but in many peoples view it is very lacking in the feature set side of things. This brought on the development of NewBB 2 by Predator, phppp and their team which is now quickly becoming the new standard for the Xoops forum module.

Content management systems such as Xoops have changed the face of how we manage our web (and other) content of recent years. As a result of these new open source, freely available management systems, supported by large online communities along with downloadable extras such as themes, templates and modules, it has never been easier to create and maintain your very own personalised web presence. The end user is now empowered to do with an annual cost as low as $100 what just a few years ago would have required a very fat wallet for a commercial product.