With the myriad .NET marketing messages broadcast from Redmond, it is easy for .NET architects and developers to miss important technical issues. However, everyone developing .NET applications should digest and act upon one particular message: Windows 2000 Server is a very powerful application server. In fact, the integration of operating system services, directory services, managed component services in .NET Framework, and Web application services provided by IIS and ASP.NET gives developers all the functionality they need to create powerful server applications.

Many application designs have yet to fully utilize the capabilities of the application server components found in Windows 2000. With Microsoft .NET Server 2003 (and the updated .NET Framework 1.1), Microsoft extends application server functionality, scalability, and performance. In fact, it is easier for companies to develop and deploy applications built on the platform for two major reasons. First, companies won’t have to cobble together their server systems by downloading features and patches from multiple locations; it’s all in the box. Second, network engineers are able to configure and tune .NET servers for application server scenarios using the Server Configuration Wizard included as part of the new release. But just knowing that Microsoft includes application server functionality doesn’t mean you are designing systems to take advantage of it. Let’s look at some of the significant new features in the upcoming .NET Server 2003 release that you should begin planning for now.

Speed, speed, speed
Speed is to applications as location is to real estate. In the end, it is the only thing that your customers use to gauge applications. One of the biggest advances in Windows .NET Server is the increased performance of the HTTP Web serving capability in IIS 6.0. Much of this performance advantage comes from the fact that HTTP caching is now done in the kernel. With caching done in the kernel, it doesn’t have to transition into user mode to serve that piece of content, resulting in dramatic performance gains.

How dramatic? With one directive change (turning on caching for ASP.NET on top of IIS 6.0), a single processor server delivering a simple cached page goes from serving 300 requests per second to over 2,500 requests per second. Being able to count on this level of performance from applications written on the .NET Framework and hosted on Windows .NET Server means that application designers have to analyze their existing standards for application partitioning and units of deployment.

Application pooling
Application pooling is another feature in IIS 6.0 that requires architects to reexamine their default deployment recommendations. Windows .NET Server application pools allow multiple Web applications to share a single worker process. By placing several Web applications in a common pool, developers and engineers may apply configuration settings to multiple applications at once. Since a unique instance of the Web application server (W3wp.exe) is loaded for each process, you can reduce the resource load on the system by using application pools. You can even tie together multiple application pools with more than one worker process to create Web gardens. Connection-based routing within a Web garden increases application availability because if one process dies, then others serve the application.

When deploying on multiprocessor servers, you can take advantage of the processor affinity features’ unique application pools. This functionality allows developers to bind an application pool process (or processes) to one or more CPUs using a mask-based configuration. In this scenario, applications are swapped out and restarted on the fly.

Moreover, Web sites can be brought up and down at will without affecting other Web sites on the same server. Also, Windows .NET Server minimizes resource consumption by only starting processes when needed. By setting processes to be shut down after a predetermined period of idle time, a single server can support more applications than prior implementations based on Windows 2000 because resources are returned to the pool for other applications. Application pooling allows finer grained partitioning of Web servers, meaning that you need to deploy fewer servers. Of course, without the performance increases we discussed earlier, you wouldn’t be able to consolidate servers. But the combination of increased performance and finer grained deployment means fewer moving parts, and therefore, less maintenance.

Given the typical six to 12 months between the initial system architecture and the ultimate deployment, .NET architects should be considering how they will take advantage of the application server features in the upcoming release of Windows .NET Server. Many of the system sizing, application performance, and deployment decisions that you would make based on the Windows 2000 platform with the .NET Framework 1.0 will need radical reexamination when you consider the significant advancements that are just around the corner with Windows .NET Server and version 1.1 of the .NET Framework.