Previewing Windows .NET Serversby Odysseas Pentakalos, coauthor of Windows 2000 Performance Guide
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.
- Windows .NET Web Server
- This is a new version that does not correspond to any version of the Windows 2000 line of operating systems. It is meant to be used as a dedicated Web server for hosting applications and Web services. Since this is the low-end configuration of the .NET Server, it is limited to servers with either one or two CPUs and up to 2GB of RAM.
- Windows .NET Server
- This is the upgrade to the Windows 2000 Server version and it is intended as a general purpose file server, printer server, Web server, etc. It is limited to servers with up to two CPUs but can support up to 4GB of RAM.
- Windows .NET Enterprise Server
- This is the upgrade to the Windows 2000 Advanced Server version and it is for use by enterprises of any size as a high-end server. It can support servers with up to eight processors and with up to 32GB of memory (on x86-based servers) or up to 64GB on Itanium-based servers.
- Windows .NET Datacenter Server
- This represents the ultimate offering, in terms of both performance and reliability, and is the upgrade to the Windows 2000 Datacenter product. It will only run on servers with at least eight processors, but it can support configurations with up to 32 CPUs. It can support up to 64GB of memory on x86-based servers, or up to 128GB on Itanium-based servers.
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.
Under the Hood
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.
Pages: 1, 2