If you have just finally finished figuring out the relationship between the various versions of operating systems coming out from Microsoft over the past couple of years, get ready to be challenged once again. The successor line to the server versions of the Windows 2000 operating system is called .NET Server and is currently available as a Beta 3 release to MSDN subscribers and other beta testers. It was originally called Whistler Server, but after the Beta 2 release it acquired a new name (despite an interim announcement that Whistler Server would be released as Windows 2002 Server). In this article I'll try to summarize what is new and exciting in this new release.
The .NET Server line of operating systems currently includes four different versions, three of which correspond almost one-to-one to the Windows 2000 Server, Advanced Server and Datacenter versions.
Note that the supported configuration limits for all four versions may or may not change before the official release of the operating systems, but you can at least use them as a guide as to what to expect from each version.
On a first look, it may appear that the changes between the 2000 versions and the .NET versions are minor. In fact, many changes were made to the kernel of the XP and .NET Server operating systems that are of interest from the performance perspective and may be visible to those of us not involved with writing device drivers. The registry is no longer limited in size by the size of the paged pool, and is now constrained only by available disk space. This was done to prevent the registry from using up most of the paged pool, removing the size limitation that was imposed on it, and to accommodate the use of the registry in practice as a database instead of simply a store of configuration information.
The performance of queries against the registry should now be faster as well, since an improved allocation algorithm for new cells is used that considers the locality of the information as its stored on the hive, while allocating space for storing this information. Related pieces of information are now allocated close to each other on the disk, as opposed to them being scattered throughout the registry files.
Most of the changes to the I/O subsystem only concern device driver developers and are not visible at higher layers, although the following few may be noticed by system administrators and other inquisitive users. When severely low-memory conditions exist, the system will throttle I/O requests down to one-page-at-a-time transfers to allow the system to continue operating. The defragmentation APIs that have been available since NT 4.0 have been extended in a number of ways. On volumes formatted with the NTFS file system, now even the MFT can be defragmented, which was not an option with Windows 2000.
The one feature that I found to be the most interesting is informed prefetching for speeding up the boot time and application startup. Informed prefetching has been a topic of much academic research, but this is the first time (to my knowledge) that it is being used in a commercial operating system. When the operating system boots, the system saves the sequence of page requests that result from having to read all of the code and data needed to get the system running. Once the system has started, the recorded data is read by a user mode service, called the Task Scheduler, which analyzes the data and generates prefetch instructions for subsequent boots. The next time the operating system is restarted, concurrently with the initialization of the device drivers, the logical prefetcher generates all of the disk I/O requests that are specified by the instructions, bringing all of the data needed into the cache. By the time all of the devices have been initialized, all of the data should be in the cache so that when the actual page faults are generated by the operating system, they can be quickly serviced from the cache.
This type of informed prefetching only works well for page fault scenarios that are repeatable, so that you can reap the benefit of collecting the sequence of page faults that occur during the initial invocation of the scenario. Since booting up the operating system typically involves the same sequence of file-read operations, it is a good candidate for prefetching. This feature is a result of customer research by Microsoft that indicated that faster boot times is one of the features demanded the most. The design objective for Windows XP was to achieve boot to a usable state in less than or equal to 30 seconds. Documentation from Microsoft indicates that the boot loader for Windows XP is four to five times faster than in Windows 2000. There are no claims made yet about .NET Server Beta 3, but since the same enhancement is available, a similar improvement should be achievable. In addition to the prefetching of disk I/O operations, a number of other optimizations were used to speed up the boot process -- we'll expand on those a little later.
By default, the logical prefetching of disk I/Os is only used on .NET Server OSs during the boot process. It can also be activated for prefetching pages that are read in during application startup, but you will need to modify the registry for that. The registry key that needs to be modified is
Management\PrefetchParameters and the value name is
EnablePrefetcher. A value of
0x00000001 indicates application-launch prefetching, a value of
boot prefetching, and a value of
0x00000003 indicates both application and boot prefetching.
The file with the prefetch instructions goes into the
%SYSTEMROOT%\Prefetch directory, but since it's a binary file, it is not readily readable.
Now, let's get back to the other boot-speeding optimizations. In previous versions of the NT-code-based operating systems, the boot loader would initialize each of the devices sequentially before moving on to the next stage of the boot process. In the XP/.NET Server OSs, the boot loader will initialize as many drivers as possible in parallel, thereby making the slowest device the critical path during start-up. At the same time in which the devices are initializing, the prefetch subsystem generates the asynchronous I/O requests that will bring into the cache the pages that will ultimately be needed. Any services that are not needed for the system to start up to the point where the logon screen is presented are postponed until after the logon screen is presented.
This makes the system seem more responsive to the user by again overlapping the initialization of certain services with the relatively time-consuming operation of having the user enter their username and password. To further speed up the I/O operations that take place in response to the asynchronous I/Os, the prefetcher service also generates a file that specifies the layout on the disk of the pages of data that will be prefetched. The optimization of the layout is achieved by the collaboration between the prefetcher service and the defragmenter, and improves the read time by reducing the number of I/O operations required and the amount of time spent doing seeks and rotations on the disk to read in the data.
To enable you to visualize the benefits of these optimizations on the boot time, Microsoft provides a tool called Bootvis, which is available as a free download from their site. Although the documentation mentions that it is meant for use with Windows XP systems, I was able to use it on my Windows .NET Server Beta 3 system with no problems. The Bootvis utility reads a boot trace file and generates charts side by side for a number of metrics including boot activity, CPU usage, and disk utilization. Figure 1 below shows charts of these three metrics, based on a trace of my system.
The Boot Activity chart illustrates the benefits of the prefetching, which is shown in the chart to totally overlap with the initialization of the devices. Even though the system is not ready for use until about 50 seconds after the system was started, the logon window appears after about 25 seconds. Clearly the little system I used for this evaluation does not do service to the prefetching scheme. While prefetching is taking place, the disk is experiencing 100% utilization. Once the system starts loading and starting the services, the bottleneck shifts to the CPU, which reaches 100% utilization and remains at that utilization level until after the user is logged in and the shell has started. The benefits of prefetching are clear from looking at the disk utilization chart while the services are starting. During that time there is very little disk activity, as the majority of the pages are already cached in memory.
Moving now to the application layer of the operating system, one component that underwent considerable changes with this release is the Internet Information Service (IIS), which is now available as IIS 6.0. As a security precaution, IIS, as well as other components of the server that were installed by default with Windows 2000, is now available as an optional component that can be installed during server configuration after the core installation process has completed. The majority of the changes focus on improving the performance and reliability of the server. In this article, we will only focus on the architectural changes and not the operational changes.
In IIS 5, there were two isolation options for Web applications running on the server. An
application could run as a process, thereby creating one process for each application
running on the system, or all of the applications could run as part of a separate process, conserving the amount of resources consumed by the Web server. This mode of operation is still available with IIS 6, but is not the default mode and needs to be set explicitly at the server level through the IIS MMC plug-in. Figure 2 shows the process structure of IIS running in IIS 5 isolation mode. In the example shown, one application is running as part of the main Web service process, using no isolation at all, and another one is set up to run as part of the single-pooled process called
IIS 6 introduces the concept of a worker process and a new isolation mode. A worker process is similar to a unique instance of
dllhost.exe that is used to host one or more applications or sites. Since more than one application can be assigned to run on a given worker process, IIS 6 uses the term "application pool" to refer to them. The main
inetinfo.exe process is now a separate, totally isolated process, with no applications running within its memory space. This increases the reliability of the Web server itself. In addition, the administrator can now control
how many worker processes are spawned and the assignment of applications to those
worker processes. This makes the configuration very flexible, in that the administrator can decide how to trade off isolation and reliability in exchange for the amount of system resources consumed by the Web applications. Figure 3 shows the process structure of IIS running in the new default isolation mode. The example shows that there are two worker processes configured, one running a single application and the second one running multiple applications.
You've probably noticed a third block in the figure, called a Web garden. When we introduced the term "worker process" earlier in this section, the explanation indicated that a single worker process forms an application pool to which Web applications and sites are assigned, but that is not always the case. When constructing an application pool, the administrator has the option to decide how many worker processes to assign to the pool. When two or more worker processes are configured as part of an application pool they form what is referred to as a Web garden. A Web garden allows an application to achieve higher scalability, since multiple processes are used to process requests on its behalf. A Web garden is like a Web farm (in that it aims to achieve higher scalability), but within the confines of a single server.
Figure 4 shows the new look of the MMC plug-in for
IIS. The tree control has a list of Web sites as before, but now it also includes a list of application pools. The example shown in the figure has four application pools configured, with the pool named "Default Application Pool" selected and expanded. Three applications have been assigned to the Default Application Pool, and the panel on the right shows the path associated with each of the applications assigned to this pool. Although we don't show this in the figure, while configuring an
application pool the administrator is given a number of choices that affect the lifecycle of the worker processes. The administrator can choose how often the worker processes should be refreshed, to ensure that they are not negatively impacted by the application (for example, they may be growing in
size due to memory leaks in the applications hosted within them); can decide how long a worker process should be idle before it is removed from the system; and can also configure the monitoring of the worker processes by the main
inetinfo.exe process, to ensure that they are restarted if there is a crash due
to an application error.
Before we close the section on IIS, we must bring up another architectural change that was made to IIS 6 that should result in a considerable performance boost. If you pay close attention to figures 2 and 3, you will notice that IIS now communicates with a component that runs within the kernel. That component is called
http.sys, and as its name implies, it is responsible for handling and dispatching requests to the
Web server coming off of the network. By having this component be part of the kernel, if a request arrives for static content and that content is already cached in memory, the Web server can respond immediately to the request without having to make a context switch to user mode.
In addition to this important performance benefit, moving this component to the kernel totally isolates this basic Web server functionality from any application code running in user mode that could cause the Web server to crash. Each application pool created by the administrator has an associated queue in kernel mode. As requests enter the system, if they cannot be serviced immediately by the
they are dispatched to the appropriate kernel queue from where they are picked up for processing by one of the worker processes associated with that application pool.
Another improvement in Windows .NET Server is the release of a large number of command line utilities for assisting with system management tasks. We are not going to discuss every single one of them here, but we'll review some of the more interesting ones.
logman utility allows you to manage, from the command line, a performance counter collection task. By passing options, you can specify whether a new collection is started or whether an existing one is stopped or deleted. For
example, the command:
Logman create counter daily_perf_log -b 7/27/2000 13:00:00 -e 7/27/2000 15:00:00 -r -v mmddhhmm -c "\Processor(_Total)\% Processor Time" "\Memory\Available bytes" -si 00:15 -o "c:\perflogs\daily_log"
will cause the system monitor to collect the two specified metrics starting and ending at the given times with a sampling interval of 15 seconds, and store the output in the file
daily_log. The example shown above comes straight
from the page for the
logman utility from the much-enhanced help facility. The
relog utility can be used to resample existing log files and save selected metrics to a new log file. The
typeperf utility allows you to periodically print on the console the value of certain performance metrics.
DiskPart utility is a text-mode command interpreter that allows you to manage disks, partitions, or volumes. Then there are
driverquery for looking at installed drivers and their configuration properties,
for managing printer jobs,
prncnfg for managing printers and their configurations, and
prnqctl for starting, stopping and pausing printers. The
sc utility comes with a huge number of options that together
provide a complete solution for managing services on a server from the command line. You can do anything from installing and starting a service to changing its textual description. Finally, the
will appeal to the Unix fans in that they allow you to look at the list of running proceses and kill unwanted ones all from the command line.
In this article, we tried to cover some of the more interesting features of this new line of server operating systems from Microsoft. Comparing this transition to that from Windows NT to Windows 2000, it seems like more of an incremental release than a major new release, despite what you might guess by the complete change in the naming scheme. The focus of this new release is on improving the reliability, performance, and security of the server. The enhancements to the boot process are clearly noticeable, and the new release of IIS offers lots of new features that are intended to bring out the best of the built-in .NET Framework that you've been hearing so much about.
Odysseas Pentakalos has been an independent consultant for 10 years in performance modeling and tuning of computer systems and in object-oriented design and development.
O'Reilly & Associates recently released (December 2001) Windows 2000 Performance Guide.
Sample Chapter 5 Multiprocessing, is available free online.
For more information, or to order the book, click here.
Copyright © 2009 O'Reilly Media, Inc.