MSDN Magazine - January 2008 - (Page 59)

”System.Web.Security.FormsAuthenticationModule” /> Add the SEF url rewriting module --> name=”QdigSEFUrlsModule” type=”QdigModules.QdigSEFModule” /> Add the response filter module --> name=”QdigSEFFilterModule” type= ”QdigModules.QdigSEFFilterModule” /> <!-<add <!-<add ASP.NET Output Caching After refreshing the Qdig page at http://myphpgallery/ and logging in, all of the hyperlinks on the page have changed to use the friendly URLs (see Figure 8). So far, I haven’t had to change a single line of the original application, after making several significant upgrades to its functionality with existing ASP.NET features and new functionality developed for the ASP.NET Integrated pipeline. At this point, I have added quite a bit of functionality to Qdig, even though I haven’t changed any of the application’s source code. So how much does all this new functionality impact the performance of the application? Performance has historically been a concern for PHP applications on the IIS platform due to the process-launching overhead of the CGI mechanism on Windows. FastCGI support promises to significantly improve application performance by removing this overhead, making IIS a much more attractive platform for hosting PHP and other FastCGI-compliant applications. However, if the application enhancements I just introduced add a significant portion of this overhead back, they may not be so attractive after all when considering deploying PHP applications on IIS. In reality, however, the feature enhancements I added have little effect on Qdig’s performance. Figure 9 shows a summary of the performance tests I performed on the application. The test was performed with the Microsoft Web Capacity Analysis Tool (WCAT) 6.3 using 100 concurrent virtual clients with full CPU utilization on the server, requesting a series of Qdig URLs inside the gallery. For the last test, friendly URLs were used instead of Qdig URLs to utilize the conversion functionality. Authentication was disabled for ease of testing. Moving from CGI to FastCGI, you see an improvement of almost three times the throughput. After adding the two friendly URL modules, I only saw a 5 percent drop in throughput, which is negligible. Unfortunately, Qdig is extremely CPU-bound, which negates the bulk of the possible improvement provided by FastCGI. By comparison, for a simple hello.php script, I saw an improvement of 43 times the throughput when going from CGI to FastCGI. Even after adding a response filter—a pretty expensive operation—the impact on overall throughput is negligible in comparison with the overhead of the application itself. This is pretty much the worst situation to be in as far as server performance tuning is concerned, because there is very little you can do outside of the application to improve its performance. Changing the application code itself is often impossible unless you are the application’s developer, and even then it may be difficult. For me it’s certainly out of scope as I decided not to modify the application itself when I started. Testing Performance The output cache is a feature of ASP.NET that allows reuse of responses produced by Web applications for subsequent requests to the same resources. In fact, ASP.NET provides an extensive set of features for caching both application data inside ASP.NET applications with its Cache API and an application’s entire responses with the output cache. Both features can often enhance an application’s performance and significantly reduce the load on the back-end resources. New in IIS 7.0 is the ability to use the ASP.NET output cache for non-ASP.NET content types, which is exactly what I will use to give the image gallery a little boost. As opposed to piecemeal application performance tuning that often requires a large coding effort and removes chunks of the application’s processing overhead, output caching tends to remove virtually the entire overhead for a percentage of the request workload. Its effectiveness depends on the locality of the application’s usage: how often the same content is requested by the application’s users. For typical applications, this often falls into the 90/10 rule, which basically means that 90 percent of requests always go to 10 percent of your content. If you can output-cache this content, it may mean a near 90 percent throughout and capacity improvement to your application. Of course, if it was so easy to do, everyone would be doing it. Figure 8 The Revised Gallery with Friendly URLs Figure 9 Performance Results Test Qdig with CGI Qdig with FastCGI Qdig and friendly URLs with FastCGI Hello.php with CGI Hello.php with FastCGI Requests per Second (more is better) 32 93 88 51 2239 IIS 7.0 Extensibility january2008 59

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2008

MSDN Magazine - January 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Cutting Edge IIS 7.0 - Enhance Your Apps with the Integrated ASP.NET Pipeline World Ready - Around the World with ASP.NET AJAX Applications WCF Syndication - HTTP Programming with WCF and the .NET Framework 3.5 Wicked Code Foundations Extreme ASP.NET {End Bracket}

MSDN Magazine - January 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.