Security-Specific Terms | Meaning |
User | An individual user connected to a service. |
Concurrent User | A user active on the system; a subset of total users calculated based on user profile. |
Member | An individual who has information in the Membership Directory. |
Attributes | Specific information associated with a file or an object. |
Broker | The code that runs on the Web server that does caching and authentication. |
Negotiate | The first phase of an HTTP GET request that is secured. The client makes a request for a page and the server responds with the type of authentication necessary to view the page. |
Directory | Repository for all user information, including a password. |
Least Squares | Method of approximating a polynomial equation onto a non-linear data set. |
General Terms | Meaning |
Pentium Pro equivalent MHz (PPEM) | A unit of measure for processor work.
A 200 Pentium Pro equivalent MHz is delivered by a 200 MHz Pentium Pro processor. A computer with two 200 MHz Pentium Pro processors will deliver 400 Pentium Pro equivalent MHz. |
Microsoft® Site Server 3.0 supports two security modes: Membership Authentication mode and Microsoft® Windows NT® Authentication mode. Each mode has a specific set of identification and authentication methods. The preferred mode depends entirely on the needs of a particular site. Intranet and Internet sites have different security needs, as do Web sites that host large user communities.
The two security modes can be used alone, in combination, or in combination with Microsoft® Windows NT Server’s Internet Information Server (IIS) services Anonymous access.
Windows NT Authentication mode supports the following identification and authentication methods:
Membership Authentication mode supports these identification and authentication methods:
A model is designed in which total resource cost is calculated for a variable number of concurrent users. Essentially:
C = n × K
where C is the resource cost, n is the number of concurrent users, and K is the sum of the costs of each user operation.
Separate equations are created for each type of resource (CPU, memory, disk, and network). Thus, it is possible to predict intelligently the maximum number of users a particular hardware configuration can support, or conversely, the required hardware resources for a given number of users.
The accuracy of these calculations is confirmed by comparing the results of the calculations with a series of verification tests. A test script is created that simulates a typical user behavior as defined in the user profile. The predicted resource costs calculated from the model are charted against actual resource costs generated by running the verification script.
Note Your performance numbers may vary from those provided here based on your hardware and software platform.
Processor Scaling
Web Server1: | CPU: | 4,2,1 x 200 MHz Pentium Pro |
Memory: | 512 MB of RAM | |
Network: | 100BaseT switched | |
Software: | Windows NT 4.0 Option Pack version 622 (final) |
1. To test the scaling of the authentication service, the number of processors in the Web server was varied at one, two, and four.
LDAP Server: | CPU: | 2 x 200 MHz Pentium Pro |
Memory: | 256 MB of RAM | |
Network: | 100BaseT switched | |
Software: | Windows NT 4.0 Option Pack version 622 (final) |
SQL Server: | CPU: | 4 x 200 MHz Pentium Pro |
Memory: | 512 MB of RAM | |
Disk: | 6 x 9.1 GB disks in a Hardware RAID 5 implementation, 100 percent write cache enabled | |
Network: | 100BaseT switched | |
Software: | Microsoft® SQL Server™ 6.5 SP3 |
Whether you choose Membership Authentication mode or Windows NT Authentication mode depends on the sensitivity and value of a site's data, the client software that the site supports, and the expected threats to the site. Choosing between security and performance is a trade off. The less secure methods are generally faster or easier to administer.
In general, transactions are separated into pairs. The first part of the pairing represents the first page request a user makes to a secure page. When this first request is made, the Web server returns an access-denied error to the client and requests user credentials. This is the negotiation phase and is more expensive.
Although the initial transaction includes the negotiation phase, the second transaction contains multiple page requests. Subsequent page requests do not require negotiation. Typically, a Web browser continues to pass credentials to the same Web server for subsequent requests. In these transaction groups nine additional page requests were made.
The Automatic Cookie Authentication scenario is a special case, and is broken down into three parts. In the first scenario, the first time a user visits an Automatic Cookie Authentication- protected site, a new user is created in the Membership Directory, which is quite expensive. The second scenario models a new user who visits the site for the first time and then performs nine more page requests using the new cookie. The third scenario is a user who already has a cookie and performs page requests.
There are no additional objects on any of the Web pages used for the analysis.
Transactions
Method | Description |
Automatic Cookie | Automatically creates a new user each time in the SQL Server database for each anonymous connection. |
Automatic Cookie with credentials | User encounters initial authentication and makes more requests with credentials. |
Automatic Cookie, no creation | User with a cookie returns to the site, and does not encounter a negotiation phase. |
Membership Basic Authentication | Authenticates using the name and password from the Membership Directory. This authentication method sends the user name and password unencrypted across the network. |
Membership Basic Authentication with credentials | User encounters initial authentication and makes more requests with credentials. |
DPA | Authenticates using DPA with the name and password from the Membership Directory. This method has a challenge and response. |
DPA with credentials | User encounters initial authentication and makes more requests with credentials. |
HTML Forms | Authenticates by redirecting the user to an HTML form where the user POSTs a name and password, which is then compared against the Membership Directory. |
HTML Forms with credentials | User encounters initial authentication and makes more requests with credentials. |
Windows NT Basic | Authenticates using the name and password from Windows NT, but passes it in clear text format. |
Windows NT Basic with credentials | User encounters initial authentication and makes more requests with credentials. |
NTLM | Authenticates using the name and password from Windows NT using standard Windows NT security. |
NTLM with credentials | User encounters initial authentication and makes more requests with credentials |
The security user profile is determined by planning a typical Web user visit to an authenticated site. In this example, the typical user visits the site for an average of 10 minutes. During the 10-minute visit, the user will visit five Web pages. All of these Web pages are authenticated. The first 4 pages are secured with Automatic Cookie Authentication. The users already have cookies, so their cookies will not have to be created in the Membership Directory. Their fifth page GET will be secured with Membership Basic Authentication. At this point, the user will have to enter a name and password.
All pages requested have no additional objects.
Web Client
Elements | Values | Frequency |
Average length of session | 10 minutes | |
Number of pages accessed during session | 5 | |
Percentage of pages that are authenticated | 100% | |
Percentage of pages that are automatically authenticated with preexisting cookies. For example, no cookie creation. | 80% | .006667 per sec |
Percentage of pages using Membership Basic Authentication. | 20% | .001667 per sec |
Based on the data collected in this document, the following assertions can be made about scaling and performance:
Maximum Authentications per Second
Method | Four Proc | Two Proc | One Proc |
Automatic Cookie | 11 | 11 | 10 |
Automatic Cookie with credentials | 92 | 93 | 77 |
Automatic Cookie, no creation, with credentials | 502 | 499 | 538 |
Membership Basic | 235 | 171 | 145 |
Membership Basic with credentials | 489 | 520 | 338 |
DPA | 248 | 107 | 91 |
DPA with credentials | 363 | 370 | 213 |
HTML Forms | 95 | 80 | 73 |
HTML Forms with credentials | 430 | 473 | 320 |
Windows NT Basic | 121 | 125 | 103 |
Windows NT Basic with credentials | 311 | 273 | 245 |
NTLM | 107 | 116 | 95 |
NTLM with credentials | 120 | 129 | 101 |
Every authenticated user adds to the resource overhead of the Web server running the Broker Service. Additionally, if the requested user information is not cached in the broker, then a request is made to the LDAP server, which will in turn request the user information from the SQL Server. NTLM and Windows NT Basic Authentication are not supported in the broker service and its cache.
The PPEM costs of the transactions for Authentication are not all constants. They vary with the rate of the transaction. When the transaction rate is low, the costs tend to be higher, and likewise, when the transaction rate becomes higher, the costs of some of the transactions rise. Thus, the PPEM is not always a constant; it could be a downward or upward slope. This table represents the least squares approximation of the PPEM versus Transaction Rate curves that were measured in the test environment. The relative accuracy of these measurements is confirmed in the following verification section.
The PPEM at a given rate on a given processor equals C1 + C2r.
Refer to Appendix A for a detailed explanation and example of how PPEM is calculated.
Formulas for Calculating Expected CPU
Four-processor
Authentication Method | Valid Range for r | PPEM C1 |
Automatic Cookie | 1 - 11 | 2.13 |
Automatic Cookie with credentials | 1 - 92 | 1.33 |
Automatic Cookie, no creation | 1 - 502 | 0.56 |
Membership Basic | 1 - 235 | 2.38 |
Membership Basic with credentials | 1 - 489 | 1.08 |
DPA | 1 - 248 | 2.1 |
DPA with credentials | 1 - 363 | 1.85 |
HTML Forms | 1 - 95 | 6.11 |
HTML Forms with credentials | 1 - 430 | 1.24 |
Windows NT Basic | 1 - 121 | 3.65 |
Windows NT Basic with credentials | 1 - 311 | 1.8 |
NTLM | 1 - 107 | 3.3 |
NTLM with credentials | 1 - 120 | 1.74 |
Two-processor
Authentication Method | Valid Range for r | PPEM C1 | PPEM C2 |
Automatic Cookie | 1 - 11 | 0.84 | |
Automatic Cookie with credentials | 1 - 93 | 0.45 | |
Automatic Cookie, no creation | 1 - 499 | 0.49 | |
Membership Basic | 1 - 171 | 2.08 | |
Membership Basic with credentials | 1 - 520 | 0.78 | |
DPA | 1 - 107 | 3.26 | |
DPA with credentials | 1 - 370 | 1.05 | |
HTML Forms | 1 - 80 | 3.30 | |
HTML Forms with credentials | 1 - 473 | 0.66 | |
Windows NT Basic | 1 - 125 | 1.72 | 0.0038 |
Windows NT Basic with credentials | 1 - 273 | 0.92 | |
NTLM | 1 - 116 | 2.53 | -0.0009 |
NTLM with credentials | 1 - 129 | 2.08 | 0.0015 |
One-processor
Authentication Method | Valid Range for r | PPEM C1 |
Automatic Cookie | 1 - 10 | 1.29 |
Automatic Cookie with credentials | 1 - 77 | 0.39 |
Automatic, no creation | 1 - 538 | 0.4 |
Membership Basic | 1 - 145 | 1.19 |
Membership Basic with credentials | 1 - 338 | 0.64 |
DPA | 1 - 91 | 2.2 |
DPA with credentials | 1 - 213 | 0.75 |
HTML Forms | 1 - 73 | 2.9 |
HTML Forms with credentials | 1 - 320 | 0.63 |
Windows NT Basic | 1 - 103 | 1.7 |
Windows NT Basic with credentials | 1 - 245 | 0.82 |
NTLM | 1 - 95 | 1.84 |
NTLM with credentials | 1 - 101 | 1.76 |
The following table represents the additional memory overhead associated with running this type of authentication on a Web server that is not running authentication. The calculations are not based on a per-transaction cost, but are based on the cost overhead for running any particular security method. There is an additional cost of 24K per current connection.
The memory cost was determined as follows. The Web service was restarted and the authentication service stopped. The memory usage was measured at this point. Then the authentication service was started and several authentications of the corresponding type were performed. The memory was again measured. The difference between the two measured costs represents the additional memory overhead.
Transaction | Size in Megabytes |
Automatic Cookie Authentication | 3 MB |
Membership Basic Authentication | 1.5 MB |
DPA | 2.5 MB |
HTML Forms | 4 MB |
Windows NT Basic | 1.8 MB |
NTLM | 1.5 MB |
The bitwise network traffic for security should be measured in the number of packages that constitute the overhead. The amount of bit traffic is obviously dependent on the items returned. This table describes the number of protocol roundtrips required to do the different authentications.
Method | Description |
Automatic Cookie Authentication | Creation phase generates 3 roundtrips |
Automatic Cookie Authentication with credentials | 1 roundtrip for the non-creation requests |
Automatic Cookie Authentication, no creation | 1 roundtrip per request |
Membership Basic Authentication | 2 roundtrips |
Membership Basic Authentication with credentials | 1 roundtrip for subsequent requests |
DPA | 3 roundtrips |
DPA with credentials | 1 roundtrip for subsequent requests |
HTML Forms | 2 roundtrips and 1 redirect |
HTML Forms with credentials | 1 roundtrip for subsequent requests |
Windows NT Basic | 2 roundtrips |
Windows NT Basic with credentials | 1 roundtrip for subsequent requests |
NTLM | 3 roundtrips |
NTLM with credentials | 1 roundtrip for subsequent requests |
The chart below shows SQL Server resource utilization per transaction type. The cached queries do not make any requests to the SQL Server. This chart also assumes that the user information is not in the broker cache. The PPEM for the user password search is low. Furthermore, when the user password is retrieved, all of the user’s other data is retrieved, as well, which speeds up subsequent user request information. This chart further assumes a small member object size. If the member size is larger than one SQL Server disk read, then the Read Data operations will be higher.
Transaction | PPEM | Read data | Write data | Read log | Write log |
Automatic Cookie create | 6 | 2 | 5 | 1 | 1 |
Membership Basic Authentication | 0.22 | 1 | 0 | 0 | 0 |
DPA | 0.22 | 1 | 0 | 0 | 0 |
HTML Forms | 0.22 | 1 | 0 | 0 | 0 |
Windows NT Basic | 0.22 | 1 | 0 | 0 | 0 |
NTLM | 0.22 | 1 | 0 | 0 | 0 |
Resource usage calculations are created to answer the question: What is the cost to support a given number of users? Given this information, the next question is: What is the maximum number of users this configuration of resources can support?
In order to determine capacity for each resource, equations can be designed that measure resource cost against number of users.
An examination of the user profile needs to occur before looking at specific components of the CPU, disk, and network calculations. Using the number of concurrent users to determine maximum capacity is difficult if user behavior is not taken into consideration.
Multiplying the user profile by the number of users generates this table. For example, 500 users multiplied by the frequency of cookie authentication per second (0.006667) gives 3.33 cookie authentications per second on the server.
The following table is an expansion of this concept by user count and the transactions in the user profile space.
User Profile Frequency
Concurrent Users | Auto Cookie Auth per Sec. | Membership Basic Auth per Sec. | Total per Sec. |
500 | 3.33 | 0.83 | 4.17 |
1,000 | 6.67 | 1.67 | 8.33 |
1,500 | 10.00 | 2.50 | 12.50 |
2,000 | 13.33 | 3.33 | 16.67 |
2,500 | 16.67 | 4.17 | 20.83 |
5,000 | 33.33 | 8.33 | 41.67 |
7,500 | 50.00 | 12.50 | 62.50 |
10,000 | 66.67 | 16.67 | 83.33 |
20,000 | 133.33 | 33.33 | 166.67 |
25,000 | 166.67 | 41.67 | 208.33 |
This graph exhibits the scaling behavior of the user profile across multiple processors.
The following tables show the individual data values used to generate the graph.
Four-processor
Concurrent Users | Cookie PPEM | Membership Basic PPEM | Total PPEM | %CPU |
500 | 6.42 | 1.32 | 7.74 | 0.97 |
1,000 | 12.85 | 2.64 | 15.48 | 1.94 |
1,500 | 19.27 | 3.96 | 23.23 | 2.90 |
2,000 | 25.69 | 5.29 | 30.98 | 3.87 |
2,500 | 32.12 | 6.62 | 38.74 | 4.84 |
5,000 | 64.23 | 13.35 | 77.58 | 9.70 |
7,500 | 96.35 | 20.18 | 116.53 | 14.57 |
10,000 | 128.47 | 27.13 | 155.59 | 19.45 |
20,000 | 256.93 | 55.97 | 312.91 | 39.11 |
25,000 | 321.17 | 71.04 | 392.21 | 49.03 |
50,000 | 642.33 | 152.85 | 795.19 | 99.40 |
Two-processor
Concurrent Users | Cookie PPEM | Membership Basic PPEM | Total PPEM | %CPU |
500 | 2.97 | 0.92 | 3.88 | 0.97 |
1,000 | 5.93 | 1.83 | 7.77 | 1.94 |
1,500 | 8.90 | 2.75 | 11.65 | 2.91 |
2,000 | 11.87 | 3.67 | 15.53 | 3.88 |
2,500 | 14.83 | 4.58 | 19.42 | 4.85 |
5,000 | 29.67 | 9.17 | 38.83 | 9.71 |
7,500 | 44.50 | 13.75 | 58.25 | 14.56 |
10,000 | 59.33 | 18.33 | 77.67 | 19.42 |
20,000 | 118.67 | 36.67 | 155.33 | 38.83 |
25,000 | 148.33 | 45.83 | 194.17 | 48.54 |
50,000 | 296.67 | 91.67 | 388.33 | 97.08 |
One-processor
Concurrent users | Cookie PPEM | Membership Basic PPEM | Total PPEM | %CPU |
500 | 2.23 | 0.97 | 3.20 | 1.60 |
1,000 | 4.47 | 1.93 | 6.40 | 3.20 |
1,500 | 6.70 | 2.90 | 9.60 | 4.80 |
2,000 | 8.93 | 3.87 | 12.80 | 6.40 |
2,500 | 11.17 | 4.83 | 16.00 | 8.00 |
5,000 | 22.33 | 9.67 | 32.00 | 16.00 |
7,500 | 33.50 | 14.50 | 48.00 | 24.00 |
10,000 | 44.67 | 19.33 | 64.00 | 32.00 |
20,000 | 89.33 | 38.67 | 128.00 | 64.00 |
25,000 | 111.67 | 48.33 | 160.00 | 80.00 |
The number of roundtrips for authentication per user is one each for the first four cookie authentications plus two for the Membership Basic Authenticated page.
This scenario generates a total of six round trips per visit.
The following table enumerates the expected disk reads on the SQL Server for the authentications. These numbers are not measured, but are logically determined because SQL Server requires a read from the user directory to retrieve the password information for a user.
One disk read will occur for the group of cookies and one for the Membership Basic Authentication information.
It should be noted however that the Authentication Service reads the entire user object that contains the cookie information as well as the additional password. So, it should not be necessary to make this additional read. However, in this scenario the additional request is performed. This user makes a unique call into the Membership Basic- secure section of the Web site. This call requires a separate read from disk.
Additionally, these disk numbers assume that the index for the members is in the cache. For a worst-case scenario it should perform four reads per user lookup. Although in that scenario the SQL Server computer is severely overloaded and more RAM should be added to increase the caching.
Concurrent Users | Disk Read for Cookie | Disk Read for Membership Basic | Total Disk Reads |
500 | 0.83 | 0.83 | 1.67 |
1,000 | 1.67 | 1.67 | 3.33 |
1,500 | 2.50 | 2.50 | 5.00 |
2,000 | 3.33 | 3.33 | 6.67 |
2,500 | 4.17 | 4.17 | 8.33 |
5,000 | 8.33 | 8.33 | 16.67 |
7,500 | 12.50 | 12.50 | 25.00 |
10,000 | 16.67 | 16.67 | 33.33 |
20,000 | 33.33 | 33.33 | 66.67 |
25,000 | 41.67 | 41.67 | 83.33 |
50,000 | 83.33 | 83.33 | 166.67 |
This example illustrates how to determine an optimal configuration for a given number of users.
200,000 total users
4 percent online at peak time = 8,000 concurrent users
Determine the transaction rate T for the individual transactions that make up the user profile.
n x f = T
8000concurrent users * 0.006667frequency for cookie auth = 53.33 = Tcookie
8000concurrent users * .001667frequency for basic auth = 13.33 = T membership basic
PPEM = T * cost
2-proc: PPEMcookie = 53.33 * 0.49 = 26.13 PPEM
2-proc: PPEMm. basic = 13.33 * 2.08 = 27.73 PPEM
For a total of 53.86 PPEM which is 13.46 percent CPU utilization on a two-processor computer.
Disk Reads = T * cost
Disk Readcookie = 13.33 * 1 disk reads/sec
Disk Readm.basic = 13.33 *1 disk reads/sec
For a total of 26.66 SQL Server disk reads per second.
This calculates the number of accesses necessary to read the user information in order to fill the broker cache. Each lookup operation costs .22 PPEM on the four-processor SQL Server.
SQL PPEMcookie = 13.33cookie lookups * 0.22member lookup cost = 2.93 PPEM
SQL PPEMm. basic = 13.33m. basic lookups * 0.22member lookup cost = 2.93 PPEM
For a total of 5.87 PPEM or .73-percent CPU utilization.
To calculate the PPEM from observed data, the load was simulated on a per transaction basis. In this case, Automatic Cookie Authentication cached with creation. An automated script was run that cycled through a changing user load. The values were captured in a perfmon.exe log file. This log file was then exported to a tab-delimited text file and imported into Microsoft® Excel. Next, using an Excel macro, the log was distributed and averaged. Each row in the chart below represents several minutes of the transaction load. Many values are captured, too, but these figures are the most important for calculating PPEM.
To establish a valid range of samples, context switches are observed. The context switch rate must be below a certain threshold to be considered running optimally. However, the processor should be exercised across a full range.
This table represents the actual counter objects and values of the system during simulation.
DPA Auth successes/sec | Current connections | % Total processor time | Context switches/sec | PPEM |
Site Server Authentication Service | Web Service | System | System | |
3.69 | 1.00 | 0.60 | 541.05 | 1.31 |
7.58 | 2.00 | 1.43 | 804.69 | 1.51 |
15.42 | 3.84 | 8.55 | 1224.58 | 4.43 |
28.09 | 7.15 | 8.72 | 2106.31 | 2.48 |
53.75 | 12.29 | 15.59 | 3403.49 | 2.32 |
89.35 | 26.20 | 33.70 | 5063.99 | 3.02 |
91.46 | 37.73 | 49.90 | 4441.05 | 4.37 |
90.81 | 52.23 | 27.93 | 4687.99 | 2.46 |
In the next chart, below, total processor time is multiplied by the clock capacity of the system, which in this case is 4 x 200, and then is divided through by the number of authentications per second. Next, the overall PPEM is calculated by taking a polynomial fit using least squares approximation of the PPEM value at the transaction rate. This equation generates the formulas presented in Chapter 1 for each transaction.
In this case, the best fitting is a constant value.
The user profile was then tested and run in the lab. The site had five Web pages: a.htm through e.htm. The first four were protected with Automatic Cookie Authentication and e.htm was protected with Membership Basic Authentication. The test client computers were running InetMonitor. They used a cookie list file with 96 valid cookies. When the client hit the e.htm page, the client and the broker switched to basic authentication and used the password for the user. The script paused between GET requests to simulate a user reading their information. This script is included in Appendix D.
The following table shows the data that were collected while testing the Web server with four processors enabled.
Five hundred users were run against the system for 10-15 minutes so that stability could be achieved. These PerfMon results were averaged over a 1,000-second period. PerfMon recorded the actual number of authentications of each type per second. In order to calculate expected CPU on this four-proc system, the number of Automatic Cookie Authentications was multiplied by the PPEM value to achieve an overall PPEM calculated for Automatic Cookie Authentication. For example, at 500 users the 32.90auto cookie * 0.56PPEM 4proc auto-cookie = 18.42 PPEM.
This process was repeated for Membership Basic Authentication costs. Then, the CPU % was calculated by adding the 2 PPEM values and dividing through by PPEM of the four-processor system. For example, 18.42PPEM Auto-cookie + 16.85PPEM M.basic = 35.27PPEM Total = 35.27 / (4 x 200) = .044 = 4.4% CPU.
Users | 500 | 1,000 | 1,500 | 2,000 | 2,500 |
% Processor | 5.26 | 12.10 | 12.90 | 18.70 | 25.50 |
Context Switches | 579.00 | 1691.00 | 1840.00 | 2302.00 | 2520.00 |
Get Requests | 49.10 | 169.50 | 193.40 | 246.00 | 296.00 |
Non-anonymous user/sec | 41.00 | 141.50 | 162.60 | 204.00 | 247.00 |
Automatic Cookie Authentication | 32.90 | 114.00 | 131.40 | 163.50 | 197.00 |
Basic Authentications/sec | 8.10 | 27.50 | 31.20 | 40.50 | 50.00 |
PPEM Basic | 16.85 | 57.20 | 64.90 | 84.24 | 104.00 |
PPEM Cookie | 18.42 | 63.84 | 73.58 | 91.56 | 110.32 |
CPU Calculated | 4.41 | 15.13 | 17.31 | 21.98 | 26.79 |
This is the two-proc table for the same verification scenario.
Concurrent users | 500 | 1,000 | 1,500 | 2,000 | 2,500 |
% Processor | 8.13 | 15.77 | 18.20 | 26.20 | 35.20 |
Context Switches | 450.00 | 738.00 | 156.00 | 1516.00 | 1711.00 |
Get Requests | 50.22 | 100.30 | 149.80 | 199.00 | 249.50 |
Non-anonymous user/sec | 41.60 | 83.25 | 124.80 | 166.40 | 208.00 |
Automatic Cookie Authentication | 33.44 | 66.66 | 99.60 | 133.40 | 166.90 |
Basic Authentication/sec | 8.16 | 16.59 | 25.20 | 33.00 | 41.10 |
PPEM Basic | 9.47 | 19.24 | 29.23 | 38.28 | 47.68 |
PPEM Cookie | 16.39 | 32.66 | 48.80 | 65.37 | 81.78 |
CPU Calculated | 6.46 | 12.98 | 19.51 | 25.91 | 32.36 |
This graph shows an approximate comparison of the processor configurations versus the cost for each operation. It is only approximate because it ignores the second term for several PPEM values. It does, however, accurately reflect the relative inefficiency of the four-processor configuration.
All counters noted can be found in the Windows NT Performance Monitor. These counters will be distributed among the computers in the Personalization and Membership (P&M) service group. The counters in the system and memory objects can be used to monitor capacity.
Connection Current
Static Search per second
Automatic Cookie Authentication Successes per second
ClearText Authentication successes per second
DPA successes per second
HTML Forms Authentication successes per second
Requests served from cache
SQL Server I/O transactions per second
Disk Writes/secondDisk activity should not sustain maximum transaction rate
Disk Reads/second
Requests/second
Current requests
NonAnonymous Users/second
Get requests
Context switches/second should be fewer than 15,000
%Total Processor should be less than 80 percent
%Processor Utilization (average)should be less than 80 percent (for each processor)
Available Bytesshould be greater than 4 MB
Set up to verify:
USER tstRANDNUMBER(1,1000) password
GET url:/verify/a.htm
SLEEP 120000
GET url:/verify/b.htm
SLEEP 120000
GET url:/verify/c.htm
SLEEP 120000
GET url:/verify/d.htm
SLEEP 120000
GET url:/verify/e.htm
SLEEP 120000
Information in this document, including URL and other Internet web site references, 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.
© 1998-2000 Microsoft Corporation. All rights reserved.
Microsoft, Windows and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries/regions.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.