MS Personal Web Pages Performance and Capacity Analysis
April 1999
Microsoft Corporation
On This Page
Definition of Terms
| Term | Meaning |
DNS Round Robin | A mechanism used for load balancing multiple front-end servers sharing the same Domain Name Server (DNS) host name. DNS is the Internet standard used for mapping Internet Protocol (IP) addresses to host names. |
ISAPI filter | The Internet Service API (ISAPI) filter is an application based on the Internet Service API that converts standard URL requests from Web browsers into path names addressable by the Web server's local file system. |
Server Message Block (SMB) | The Microsoft® Windows NT® network file sharing protocol used between the file redirector and server. |
Virtual directory (Vdir) | Vdirs are the SMB shares of the file store. |
LDAP | Lightweight Directory Access Protocol is an Internet standard (RFC 1777, 2250) for accessing directory services based on a simplified X.500 model. Membership Directory information is accessed using LDAP. |
Membership Directory | The Microsoft® Site Server directory services component of MCIS that contains Personal Web Pages (PWP) account information stored in a Microsoft® SQL Server™ database and accessed using LDAP. |
SQL Server | A client-server database based on Structured Query Language. It is used in PWP to store Membership Directory information. |
InetMonitor | A performance tool used to simulate load on an Internet service. InetMonitor is part of the MCIS 2.0 Resource Kit. |
Symmetric Multiprocessing (SMP) | SMP servers were used to collect data for the performance analysis in this paper. |
ceiling(x) | The least positive integer greater than x. |
Overview
Microsoft Personal Web Pages (PWP) is a Web hosting service included with Microsoft® Commercial Internet System (MCIS) 2.5. This document outlines important performance characteristics of the service and proposes a model for estimating system capacity and configuration requirements.
In particular, this model correlates resource utilization with performance parameters determined by the usage profile of the service as a system of capacity equations. This model is based on Transaction Cost Analysis (TCA). The methodology of TCA as it relates to capacity planning is described in detail in the Capacity Model for Internet Transactions white paper, available in the MCIS Resource Kit, version 2.5.
Service Description
Introduction
Microsoft Personal Web Pages (PWP) enables Internet Service Providers (ISPs) to provide lightweight Web hosting to individual users of online services.
Personal Web Pages supports uploading content to PWP sites with File Transfer Protocol (FTP) and the Microsoft® FrontPage® Web authoring tool. FrontPage integrates content creation, site management, and file transfer activity. FrontPage performance and capacity analysis is not covered in this paper.
Components
The PWP components in this paper consist of three primary logical components:
| • | Web and FTP services |
| • | Microsoft® Site Server Membership Directory (with a Microsoft® SQL Server™ database) |
| • | File store directories |
Event Sequence Charts
During performance analysis, it is important to monitor the execution of Web and FTP operations as they propagate in time through each service component. Event sequence charts are presented here to help clarify this for the HTTP get and FTP put transactions.
Web Page Request
Each Web server (an IIS Web site) is configured with an ISAPI redirect filter that is used to map URL requests to directory path names. In particular, the ISAPI filter looks up each Web request specified by the URL prefix in the Membership Directory. The LDAP service then queries SQL Server to retrieve the attribute that corresponds to the physical path of the file store where the Web page is located. This attribute is called the URL substitute and is defined by a vroot and user (and hash if MCIS Administration and Provisioning System (MAPS) is used for provisioning). The filter then changes the incoming URL to this substitute path and the Web page request is completed. This sequence of operations is shown generically as an event sequence chart in Figure 1.
Figure 2 illustrates this sequence of operations with a sample configuration. In this example, the Web client requests to view bob's default.htm located at http://www.microsoft.com/bob. The ISAPI filter maps this URL to \\FileStore2\SHARE4\77\bob\default.htm, which is the physical location of the file.
Figure 2: Using the ISAPI Filter to Access a PWP Site on a Sample Configuration
See full-sized image.
FTP File Transfer
First, a control connection between the FTP client and the FTP server (an IIS FTP site) is established. Logon credentials are then passed to the FTP server, authenticated against the Membership Directory, and access rights of the Site Server Personalization & Membership (P&M) impersonation account are then checked on the file store. A data connection is established between the FTP client and the FTP server when the client attempts to upload a file. The file is then transferred through the FTP server on its way to the file store. Finally, data and control connections are dropped when the client logs out. This sequence of operations is shown in Figure 3.
Usage Profile
A usage profile is defined here that is intended to reflect the expected individual and aggregate user behavior of a PWP/FTP deployment. Characteristics derived from this profile are then used to establish performance targets. In general, the throughput target T for a given transaction in units of transactions per unit time is given by
Equation 1:
where ntransactions denotes the number of these transactions performed per user during each session, Nconcurrent denotes the number of concurrent users, and tsession denotes the length of each user session. Refer to the "Usage Profile" section in the Capacity Model for Internet Transactions white paper included in the MCIS Resource Kit version 2.5.
The following profile is intended to function only as a template for estimating key performance parameters. These parameters will vary according to each particular customer scenario.
Web Service
A 1998 Media Metrix Survey of several ISPs, including Geocities, AOL, and Yahoo!, is used as a reference to conservatively estimate projected usage of PWP. This survey shows that less than 15 percent of the total Web page user audience is online each day, with each user session persisting for less than 10 minutes, and each user requesting fewer than 20 Web pages during each session.
Concurrent Users
Consider a very large PWP deployment with 2 million user sites. Suppose that the total user audience requesting Web pages consists of 4 million users. If the number of users online is evenly distributed throughout a 20-hour day, then the number of concurrent users online is given by:
0.15*(4 million users)*(10 mins/session) / (20 hrs/day)
= 5,000 concurrent users
Assume, however, that during peak usage there are actually 2.5 times as many concurrent users as initially assumed. Then the peak concurrency becomes 12,500 users.
In general, the peak number of concurrent users requesting Web pages is given by:
where upeak denotes the peak on-line usage multiple, Naudience denotes the total user audience, aaudience denotes the fraction of this user audience online each day, tday denotes the length of a day, and tsession denotes the length of a user session.
Performance Target
Using Equation 1, the HTTP request throughput target is then given by:
FTP Service
Concurrent Users
Assume that at peak 0.2 percent of users with Web page sites are connected to their Web sites using FTP. Further, assume that each of these users performs one logon, two puts, one get, and one delete transaction over a 10-minute session.
The number of concurrent users at peak is then given by:
Performance Targets
Using Equation 1, the FTP logon throughput target is then given by:
Similarly, throughput targets for the other FTP transactions are given by:
Performance Analysis
The performance analysis given here is based on observations made with both local and remote file store configurations.
Local File Store
Configuration
Figure 4 shows the performance test configuration with a local file store.
PWP/FTP Server
CPU: | Intel Pentium II Xeon 4 x 400-MHz processors |
Memory: | 2-megabyte (MB) L2 cache, 1 gigabyte (GB) of RAM |
Disk Controller: | 2 PCI Fiber Channel disk controllers, 512 MB cache per controller |
Spindles: | 10 x 9-GB 7200 RPM per controller, NTFS RAID 0 with 32-KB stripes |
Netcard: | Intel Pro100 (100 MB/sec) |
Software: | Microsoft® Windows NT® 4.0 Server Service Pack 3, Microsoft® Internet Explorer 4.01 Service Pack 1, Windows NT 4.0 Option Pack, Microsoft® Site Server 3.0 (P&M only), Windows NT® 4.0 Service Pack 4, Internet Explorer 5 techbeta refresh (1313.1), Site Server 3.0 Service Pack 2 build 879 |
LDAP Server
CPU: | DEC Alpha 2 x 500-MHz processors |
Memory: | 4-MB L2 cache, 512 MB of RAM |
Disk Controller: | SCSI |
Spindles: | 2 x 4-GB 7200 RPM, NTFS |
Netcard: | 100 MB/sec |
SQL Server
CPU: | Intel Pentium II Xeon 4 x 400-MHz processors |
Memory: | 2-MB L2 cache, 1 GB of RAM |
Disk Controller: | 2 PCI Fiber Channel disk controllers, 512 MB cache per controller |
Spindles: | 10 x 9-GB 7200 RPM per controller, NTFS RAID 0 |
Netcard: | Intel Pro100 (100 MB/sec) |
Network
100 baseT switched Ethernet
Settings
| • | NTFS File System
| ||||||||
| • | Site Server/Internet Information Server (IIS)
| ||||||||
| • | Services
|
File Store Structure
| • | 4 virtual directories on PWP/FTP server mapped to two drive volumes on separate disk controllers. |
| • | Each drive volume contained 75 hashed subdirectories, each hashed subdirectory contained an additional 50 sub-subdirectories, and each sub-subdirectory contained 200 user directories. This equated to 750,000 users per drive volume, for a total of 1.5 million users. |
| • | Each user directory contained a 10-KB default htm file, 24-KB, 26-KB, and 27-KB jpeg images, and a 12-KB audio file. |
Performance Observations
Web Service
The following performance observations were made for the Web Service with a local file store configuration. Unless otherwise noted, HTTP get requests were performed with 10-KB default.htm files.
| • | Increasing the NTFS transaction log size from the default (4,096 KB) to the maximum (65,536 KB) and disabling NTFS last access updating increased throughput by more than 60 percent, from 45 HTTP gets/sec to 73 HTTP gets/sec. This was the maximum throughput observed with this configuration. |
| • | The maximum transaction throughput was reached before any hardware resource capacity was reached. |
| • | Processor scaling costs are approximately linear. At peak throughput, the PWP CPU cost is 7.7 MHz/transaction with 4-way SMP and 7.2 MHz/transaction with 2-way SMP. System configuration with a 400-MHz Xeon 4-way SMP PWP server was not necessary because CPU utilization did not increase beyond 35 percent with this configuration. |
| • | Network utilization did not exceed 7 percent. |
| • | This configuration was not disk I/O bound at peak throughput. The average current disk queue length for both disk controllers combined was less than 8, with 370 total disk reads/sec and less than 1 total disk write/sec. |
| • | Less than 5 percent of all Web page requests resulted in cache hits. Decreasing RAM from 1 GB to 256 MB did not significantly change this cache hit rate or request throughput. |
| • | In a fully-cached Web page request environment, throughput was limited to 707 gets/sec for 10-KB files, 137 gets/sec for 50-KB files, and 70 gets/sec for 100-KB files. In each case, these throughput limits were due to network saturation at 60 percent utilization. |
| • | No significant change in throughput occurred between settings maximum throughput for file sharing and maximum throughput for network applications. (These settings can be adjusted in Control Panel/Network/Server.) |
| • | The LDAP and SQL Server computers were not a bottleneck with this configuration. At peak throughput, the LDAP server total CPU utilization did not exceed 20 percent, with negligible disk I/O. The SQL Server total CPU utilization did not exceed 2 percent and disk reads did not exceed 46 per second with negligible disk writes. |
FTP Service
The following performance observations were made for the FTP Service with a local file store configuration. FTP transactions were performed with 5-KB files.
| • | The maximum transaction logon throughput was reached before hardware resource capacity was reached. |
| • | Logon throughput decreases considerably when performing FTP transactions while simultaneously serving HTTP requests, and so FTP and HTTP services should be separated by servers. |
| • | A maximum of 45 logons/sec was observed with all users fully uncached. Similar throughput bounds were found when only one put, get, or delete transaction was performed, but throughput for each transaction should increase if multiple such transactions occur during a single user session. |
| • | A maximum of 65 logons/sec was observed with all users cached in the disk controller and none cached in the Site Server Authentication Service. |
| • | A maximum of 900 logons/sec was observed with all user request data cached in the Authentication Service and disk controller. |
Remote File Stores
Configuration
Figure 5 shows the performance test configuration with remote files stores.
| • | One and two PWP servers; four file store servers |
| • | 3 million users |
| • | Separate tests run with 3- and 38-KB files per user |
Performance Observations
Web Service
The following performance observations were made for the Web Service with a remote file store configuration:
| • | Due to the Windows NT 4.0 Server Message Block (SMB) limitation, only 2,048 open files are permitted for each file store computer to front-end computer connection. During testing, this limit caused the system to reach maximum throughput before reaching the capacity of any system resource. (This SMB limit is increasing in Windows 2000.) |
| • | Total system throughput approximately doubled to more than 140 HTTP gets/sec with the two PWP servers. Some SMB limit errors were observed, but the error rate was within acceptable bounds. More PWP servers can be added to increase throughput until the network reaches capacity or disk I/O becomes a bottleneck on the file stores. |
| • | CPU utilization on the file stores and disk I/O on PWP servers were both negligible. In particular, total CPU utilization was less than 2 percent for each 4-way SMP file store server, and disk reads and disk writes were each less than 1/sec for PWP servers. |
Capacity Analysis
Because it is expected that most customers will deploy PWP/FTP with a remote file store configuration, the capacity analysis detailed here is given in this context. Simulations showed significant performance degradation with HTTP and FTP transactions occurring simultaneously on the same server. Therefore, running these services on separate servers is recommended.
An example that illustrates the use of the capacity equations can be found at the end of this section. For additional background, refer to the "Cost Equations" section in the Capacity Model for Internet Transactions white paper, available in the MCIS Resource Kit version 2.5.
Capacity Equations
The equations for processor and disk I/O costs presented in this section are constructed by linear interpolation of CPU utilization and disk I/O transfers, respectively, on a single 4-way SMP PWP/FTP server with a local file store under increasing user load.
With remote files stores, CPU utilization on the file stores and disk I/O on PWP servers were both negligible. In particular, total CPU utilization was less than 2 percent for each 4-way SMP file store server, and disk reads and disk writes were each less than 1/sec for PWP servers.
Therefore, a capacity characterization of the local file store configuration can be leveraged to approximately reflect utilization in a remote file store context for processor and disk resources. There are caveats, however. For example, the remote file store configuration will increase total request caching (RAM and disk controller) on the file stores and therefore reduce disk I/O relative to local file store configuration. On the other hand, there will be additional overhead for managing network connections.
The capacity characterization given here is restricted to CPU utilization on the PWP and FTP servers and disk I/O on the file stores. The equations assume that the PWP and FTP services run independently on separate servers.
Processor costs are given in units of Intel Pentium II Xeon MHz. Spindle costs are given for RAID 0 configurations. RAID 1 write costs can be estimated by multiplying RAID 0 writes by two, and RAID 1 read costs should remain approximately unchanged relative to RAID 0 estimates.
Web Service
In this analysis, the request cache hit ratio was less than 5 percent with users requesting 10-KB files.
As before, the PWP request throughput target will be denoted by THTTP, get and is given in units of HTTP gets/sec.
PWP Server CPU Cost
The total CPU cost on the PWP server to serve PWP requests in units of MHz consumed is given by
Equation 2:
Figure 6 in Appendix D shows the data interpolated to derive this equation.
This equation should also approximately reflect costs on 1- and 2-way SMP architectures, because processor scaling is approximately linear.
As indicated in the "Performance Observations" section, 73 HTTP gets/sec was the maximum attainable throughput with one PWP server. Therefore, if THTTP,get > 73 requests/sec, then the number of PWP servers that must be deployed is given by
Equation 3:
In this case, Equation 2 will still determine the total CPU capacity requirement, with the CPU cost per PWP server divided evenly among each PWP server (assuming proper load balancing).
File Store Disk I/O Cost
The total spindle read cost on the file store to serve PWP requests in units of reads per second is given by
Equation 4:
Figure 7 in Appendix D shows the data interpolated to derive this equation.
Due to the SMB limitation, four separate file store servers were required in order to sustain throughput at 73 HTTP gets/sec. Requests were randomly generated across file stores so that the disk reads/sec divide evenly between file store servers.
The number of disk writes/sec is negligible.
FTP Service
Load generation was run separately for logons, puts, gets, and deletes. Procedures were followed to ensure that the load was evenly distributed between each disk controller. Logon credentials for each of these transactions were not cached in the Broker or disk controllers, and so actual put, get, and delete costs are approximated by subtracting fully uncached logon costs from the measured put, get, and delete costs.
In this analysis, the file size for FTP transfers and deletes was approximately 5 KB.
As before, the FTP throughput target for logons, puts, gets, and deletes will be denoted by TFTP, logon, TFTP, put, TFTP, get, and TFTP, delete and given in units of logons/sec, puts/sec, gets/sec, and deletes/sec, respectively.
FTP Server CPU Cost
The total CPU cost on the FTP server for all FTP transactions in units of MHz consumed is given by
Equation 5:
Figures 8, 9, and 10 in Appendix D show the data interpolated to derive this equation.
The CPU logon cost is negligible (< 20 MHz at maximum) relative to the other FTP CPU costs, and therefore is not included in Equation 5.
As indicated in the "Performance Observations" section, 45 FTP logons/sec was the maximum attainable uncached throughput with one FTP server. Therefore, if TFTP,logon > 45 logons/sec, then the number of FTP servers that will need to be deployed is given by
Equation 6:
In this case, Equation 5 will still determine the total CPU capacity requirement with the CPU cost per FTP server divided evenly among FTP servers, assuming proper load balancing.
File Store Disk I/O Cost
The total spindle read cost on the file store for all FTP transactions in units of reads per second is given by
Equation 7:
and the total write cost in units of writes per second is given by
Equation 8:
Figures 11, 12, 13, and 14 in Appendix D show the data interpolated to derive this equation.
The number of disk writes/sec measured while performing FTP logons and gets was negligible.
LDAP Server Cost
The LDAP throughput target is determined by the total number of LDAP static searches per second required to support uncached PWP requests and FTP logons. This throughput is given by
Equation 9:
To estimate the LDAP server capacity requirements as a function TLDAP static searches, refer to the Membership DirectoryCapacity and Performance Analysis, Update Incorporating SQL Server 7.0 and Xeon Architecture available in the MCIS Resource Kit version 2.5.
Example
Following the usage profile example in the "Usage Profile" section,THTTP,get = 417 gets/sec, TFTP,logon = 6.7 logons/sec, TFTP,put = 13.3 puts/sec, TFTP,get = 6.7 gets/sec, and TFTP,delete = 6.7 deletes/sec.
PWP/FTP Server CPU Cost
Using Equation 2, the total PWP CPU cost is then given by:
And using Equation 3, the minimum number of PWP servers is given by:
Therefore, the CPU cost per PWP server is
A 1 x 500-MHz server should provide sufficient processor power in principle, but operating each server at less than 60-80 percent utilization is recommended. Therefore, six 2 x 400-MHz PWP servers should be deployed in this case.
Using the throughput targets for FTP given in the FTP Service topic in the "Usage Profile" section, a similar calculation using Equation 5 shows:
This estimate, in conjunction with Equation 6, suggests that one 1 x 400-MHz FTP server should be sufficient.
File Store Disk I/O Cost
Using Equation 4, the spindle cost to serve Web page requests is given by:
Similarly, using Equations 7 and 8, the spindle cost to process FTP transactions is given by:
Therefore, the total spindle read cost is:
and the total spindle write cost Ctotaldisk writes remains 64 writes/sec.
Because at least four file store servers must be deployed to support these throughput targets, the total required disk capacity for each file store server is:
LDAP Server Cost
Using Equation 9, in the absence of caching, the LDAP server must have capacity to support:
Appendix A - Important Monitoring Counters
The following PerfMon1 counters are useful for monitoring system performance and characterizing service usage.
| Object | Server | Counter |
FTP Service | FTP | Bytes received/sec |
| FTP | Bytes sent/sec |
| FTP | Concurrent connections |
Internet Information Services Global | PWP | Cache hit % |
| PWP | Cached file handles |
Memory | PWP, FTP, File Store, LDAP, SQL | Available bytes |
| PWP | Pages input/sec |
| PWP | Pages output/sec |
| PWP | Page reads/sec |
Network Segment | PWP, FTP, File Store | % network utilization |
Physical Disk | File Store, SQL | Current disk queue length |
| File Store, SQL | Disk reads/sec |
| File Store | Disk writes/sec |
Process | PWP | Working set (inetinfo) |
Server | File Store | Files open |
Site Server Authentication Service | FTP | Logon operation successes per second |
| PWP | Requests served from cache |
System | PWP, FTP, File Store, LDAP, SQL | % total processor time |
| PWP, FTP, File Store, LDAP, SQL | Context switches per second |
Web Service | PWP | Bytes received per second |
| PWP | Bytes sent per second |
| PWP | Current connections |
| PWP | Get requests/sec |
Appendix B - Load Generation Tool
Performance Evaluation with InetMonitor
InetMonitor 3.0 is a performance test tool provided in the MCIS 2.0 Resource Kit. InetMonitor simulates user load on a service, which helps determine the performance of a particular system configuration before the system is implemented in a production environment.
InetMonitor uses a scripting language to simulate Web page requests made by a Web browser. InetMonitor also provides a facility for increasing user load to simulate increasing numbers of concurrent users. When used in conjunction with Window NT Performance Monitor (PerfMon), resource utilization and transaction throughput can be monitored for increasing user load to determine when maximum throughput and maximum resource capacity have been reached.
For more information about InetMonitor, refer to the InetMonitor Operations Guide version 3, which is also part of the MCIS 2.0 Resource Kit.
InetMonitor 3.0 does not support FTP. A Microsoft internal tool was used to generate load for this protocol.
Appendix C - Scripts
HTTP
This is the InetMonitor 3.0 script that was used to generate client load for HTTP:
GET url:/RANDNUMBER(1,1500000)/default.htm SLEEP RANDNUMBER(400,600)
| • | This script requests a default Web page at random from a population of 1.5 million Web pages. |
| • | InetMonitor requests Web pages from the PWP server with a URL format given by "/X/default.htm" where X represents a given Web page and is chosen at random from between 1 and 1,500,000. (The PWP server receiving this request then queries LDAP to map this URL to the actual physical path of the file store.) |
| • | After each request, InetMonitor sleeps for an amount of time that is chosen randomly between 400 and 600 ms in order to reduce load on the queue of the client running this script. |
FTP
No FTP scripts are provided because the tool used to generate load was an internal Microsoft tool.
Appendix D - Resource Utilization
The following graphs show the cost equations constructed by linear interpolation of resource utilization measurements made on a PWP/FTP server under increasing load with a local store configuration.
Information in this document is subject to change without notice. The entire risk of the use or the results of the use of this resource kit remains with the user. This resource kit is not supported and is provided as is without warranty of any kind, either express or implied. The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 1999 Microsoft Corporation. All rights reserved.
Microsoft, FrontPage, Windows and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
1 Performance Monitor (PerfMon) is included with Microsoft® Windows NT® Server and Windows NT Workstation.