Export (0) Print
Expand All
1 out of 1 rated this helpful - Rate this topic

Planning for ADFS-enabled Web server capacity

Updated: December 15, 2006

Applies To: Windows Server 2003 R2

Capacity planning for Active Directory Federation Services (ADFS)–enabled Web servers helps you estimate the following:

  • The appropriate hardware requirements for each ADFS-enabled Web server

  • The number of ADFS-enabled Web servers to place in the resource partner organization

A federated application is a Web application that has been configured to be authenticated through the ADFS Web Agent on a Web server. When a Web server is running the ADFS Web Agent, it is referred to as an ADFS-enabled Web server. You can use an ADFS-enabled Web server to federate Windows NT token-based applications or claims-aware applications.

When a federated user obtains a security token and presents it to the ADFS-enabled Web server, the Web server receives the security token, validates the signature on that token, writes an authentication cookie, and then redirects the user back to the originally requested Uniform Resource Locator (URL). As the user browses the application, the ADFS-enabled Web server also makes information about the user in the security token available to the application.

Because Web applications vary widely in their performance characteristics, capacity planning for ADFS-enabled Web servers includes testing a federated application under load while the ADFS Web Agent is enabled. Using the tables below as a guide, you can see how configuring an application to use the ADFS Web Agent affects the performance of an application.

The base application does nothing beyond displaying the user name. Secure Sockets Layer (SSL) is used throughout all scenarios to keep the scenarios consistent. Make sure that you assess the impact of using SSL before using the tables as a guide to the impact on the ADFS-enabled Web server.

The following table contains capacity numbers for the base, nonfederated application with SSL turned on. You can use these numbers as a baseline to compare to an existing SSL application that is not configured for federation.

Capacity of a simple, nonfederated application

Scenario description Requests handled per second CPU consumption, percent

SSL-protected ASP.NET application using no authentication

2,068

91.25

SSL-protected ASP.NET application using Windows Integrated authentication

504

99.79

Using the nonfederated application table above as a baseline, you can use the capacity numbers in the following federation application table to estimate the impact on the ADFS-enabled Web server when it runs one or more federated applications.

The first item in the following table is the capacity for initial sign-in to the Web application. During initial sign-in, the ADFS-enabled Web server validates the token, issues a cookie, and redirects to the originally accessed URL. The requests of the user after initial sign-in are labeled “continued access” in the table. The capacity numbers for continued access are categorized by the type of application (claims-aware or Windows NT token-based). Because the mix of requests during any one second is a combination of initial sign-ins and continued access requests, the actual performance falls between the numbers for initial sign-in and continued access. The following table contains capacity numbers for the same application that is described in the previous table, except that this table includes values that are based on the ADFS Web Agent being enabled.

Capacity of a simple, federated application

Scenario description Requests handled per second CPU consumption, percent

Initial sign-in: authentication cookie issuance, given a security token from the Federation Service

585

96.41

Continued access to the Web application using the claims-based Web Agent, given the authentication cookie

949

98.38

Continued access to the Web application using the Windows NT token–based Web Agent, given the authentication cookie

712

98.79

Example

You are configuring a Windows NT token-based application to use the ADFS Web Agent so that users in the account partner can access the application. The current deployment of the application uses Windows Integrated authentication over SSL, and it can handle 250 requests per second. Looking at the table that describes the nonfederated application, the deployment of your application has approximately half the capacity of the sample application in the ADFS product team's tests before the ADFS Web Agent is enabled. It is reasonable to project for planning purposes that the capacity after the ADFS Web Agent is enabled will be approximately half the value that is specified in the table that describes the nonfederated application. Given this projection, you can project that performance to be between 290 requests per second (approximately half of the 585 initial sign-ins per second capacity) and 440 requests per second (approximately half of the 885 security identifier (SID)-based logon, continued access requests-per-second capacity), depending on the mix of initial sign-in requests and continued access requests in any given second.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.