Performance Tuning Xoops on IIS
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. The performance improvements that can be had over the default install values of Xoops and associated software in a Windows environment utilizing the Internet information Services web server can be staggering. This article specifically covers basic performance tuning of a Windows 2003 Server running Internet Information Services 6, and demonstrates that getting superior Xoops performance is as easy as 1, 2, 3.
This articles primary aim is to explore the performance differences of an Xoops website running in a single Windows server environment under an increasing traffic load, while using different configurations. Instructions of how to actually configure your server with these specific optimised configurations will not be covered in this article (they are to come), and as such if you wish to be able to apply them to your server immediately you will need to have a good working knowledge of your Windows server environment.
There will be three areas of server configuration that will be optimised for performance, and they are Xoops, PHP and IIS. This is by no means a comprehensive performance tuning guide, and there is certainly more you can do even in a single server environment to enhance performance. However the three areas that were selected for optimisation will give your server the biggest overall performance increase with the least amount of work. The details of each area required for this article are;
- Basic Xoops administration
- Xoops Module & block caching
- PHP module installation
- php.ini configuration
- IIS application mapping configuration
- Native IIS 6 compression configuration
The server used for this article was running a fresh install of Windows 2003 SP1, and was configured as a stand alone server with only the required IIS components installed. I used the default PHP 4.3.11 installer from php.net as not all Xoops modules are fully PHP5 compliant yet, and I have read of some issues with PHP 4.4 and 5.0.5 so decided to stay clear of these latest releases for the moment. MySQL 4.1.14 was installed using the standard "server" configuration selected during the setup process. Xoops version 188.8.131.52 was used as it is the most stable of the current Xoops releases, but I will be looking to update this article once the new 2.2.x branch matures.
Hardware used in the server was deliberately keep very modest so as to demonstrate that you do not need to throw buckets of processing power at Xoops in order to get it to perform. This hardware is also a better representation of what the average Xooper has, and is also more in line with the available processing power people using shared hosting services will have. The server consisted of an AMD Athlon 1.4Ghz CPU running on a 133Mhz front side bus, with 512MB of PC-133 SD-RAM and a 10GB ATA-66 5400RPM IDE hard drive.
The construction of the tests in this article were very simple. Set the test sever up with a copy of this website in a certain configuration and then record how it reacts to an increasing level of simulated traffic, change configuration and then repeat. To do this I needed some specialised software, and there were two software programs and one PHP script used to conduct the actual tests in this article. They were Microsoft's Web Application Stress Tool and IBM's Page Detailer Basic, and my own Xoops Page Execution Timer & MySQL Query Counter PHP script . There are a massive amount of different metrics available to monitor on a server in order to paint a picture of how it is performing (or not), but in the interest of keeping this article focussed only a small subset of what is available will be included.
Microsoft's Web Application Stress Tool (WAST) is a very handy piece of free ware software that you can use to generate simulated traffic on your server. Not only that but there it is also able to record a massive amount of information on your servers performance. I won't bother going into detail here as exploring WAST in any real sense would require an article on its own. I used WAST to first record my test script which simply required me to hit the record button and then open my test site in Internet Explorer. WAST recorded all the HTTP items, including all delay times between items as well as cookies. Once this script was recorded I set WAST to also monitor the CPU utilization and Memory pages/sec performance monitor counters on the test server.
IBM page detailer basic is a program that monitors Internet Explorer activity and then creates a graphical representation of the time line of items loading into your browser. In this case I was using page detailer to track the total page loading time, number of HTTP requests and size in bytes of all the contents of the webpage. The Xoops Page Execution Timer & MySQL Query Counter did pretty much just that. It was used to record the amount of time taken by the server to process the PHP script, and also record the amount of MySQL queries required to collect the data from the database to generate the page.
The basic test work flow was as follows;
- Set up server in required configuration
- Load up WAST, Page Detailer Basic, and Internet Explorer with test site loaded
- Run WAST script with a thread count of one
- Refresh Internet Explorer
- Record page execution time, MySQL queries, page loading time, total HTTP items and total content size
- When WAST script finishes record total successful hits, Bytes Sent Rate, Bytes Recv Rate, CPU and RAM performance monitor averages.
- Repeat process incrementing the WAST thread count to 5 and then multiples of 5 until it equals 20. Then setup server with next configuration to be tested and start again