Understanding Configuration and Performance

Before you begin performance testing it is very important you become familiar with several performance-related configuration aspects of your Web application. Configuration aspects such as the method of authentication and other global application settings help to give you a quick understanding of how your Web application works.

ASP.NET and ASP Web applications, while very different, can coexist on the same Web server because their file extensions are mapped to different DLLs within IIS. One major difference between ASP.NET and ASP applications is how they are configured. ASP.NET Web applications are configured by XML-based text files, where traditional ASP Web applications have many configurable parameters located in the metabase and the Registry. Storing configuration information in XML-based files makes it much easier to maintain the data in a readable format and update it on the fly without restarting the Web server.

ASP.NET File Extensions

When you first look at an ASP.NET Web application like the IBuySpy sample site you will notice many different file extensions. Some of the new file extensions that you should be familiar with are as follows:

ASPX
This extension is used for Web form pages and is very similar to the traditional ASP pages.
ASCX
These files hold the Web forms user controls. This provides one of the ways that ASP.NET reuses code.
ASMX
Files with this extension are for files that implement XML Web services.
VB
These files are for Visual Basic .NET code behind modules. When you create a Web application using Visual Basic .NET you will have a Visual Basic file associated with each Web form. These files allow for a separation of user interface elements and application logic.
CS
This extension is similar to the VB extension except that the code is written in the new C# language. Code behind modules written in C# will have the same name as the Web form with a CS extension.
Global.asax
This file is used to define application- and session-level variables and procedures when the Web application starts up or receives a request from a new user.

Authentication in ASP.NET

The three different types of authentication to use with ASP.NET Web applications are Windows, Passport, and Form-based. ASP.NET does not do all the authenticating; there are two distinct layers of authentication: IIS and ASP.NET application level. ASP.NET uses the <authentication> tag in the Web.config file to set the mode (more information on this in the next section).

Windows-based Authentication

The first authentication mode is for Microsoft Windows-based machines, where ASP.NET relies on IIS to authenticate the incoming requests. This form of authentication is primarily used for Intranet applications. The three different methods available for this configuration are Basic, Digest, and Integrated Authentication.

Basic Authentication
This method works with most browsers, but it sends all passwords in clear text. For Internet sites, this method is tolerated as long as you have enabled SSL encryption, but it is not recommended.
Digest Authentication
This method requires Windows 2000 Domain Controller and HTTP 1.1 (so it may not be supported by all browsers). The password is not sent in clear text it is a hashed value, making it a little more secure. However, the domain controller has to store a clear-text password so it can validate the password. Thus the domain controller must be safe from outside attacks.
Integrated Windows (NTLM) Authentication
This method is only available with Internet Explorer and is the most secure because it never sends the username and password over the network. It requires all users to have a Windows NT account on the Web server or the domain controller.

Passport Authentication

The second authentication mode is Passport. Passport is a centralized service provided by Microsoft which allows you to log in to any Passport-enabled site or Web application by simply using a single username and password (that is, single sign-in, or SSI).

Form-based Authentication

The last form of authentication is called form-based. This allows developers to create their own authentication within their Web applications. However, passwords are sent in clear text so make sure you add a SSL layer to protect your password. You simply create a login page and link it to ASP.NET in the Web.config file where you can set security restrictions. You can verify that username and password against a database or Windows 2000 Active Directory.

Configuration Files

ASP.NET uses a series of XML-based files to configure the Web application. The highest level configuration file is the machine.config file, which by default is located in [Your system folder]\Microsoft.NET\Framework\versionx.x.x\CONFIG\. This file contains the default settings for all ASP.NET applications on your server.

NOTE
You must exercise great caution when editing this file because it affects all ASP.NET Web applications on the server.

There is another configuration file named Web.config that is specific to each application you create. Every Web application you create using Visual Studio .NET automatically creates this file for you. Do not worry if you are not using Visual Studio .NET to create your application. If there is no Web.config file, the application will inherit default values from the machine.config file. We will take a quick run through some of the values represented in these files to provide better understanding of the power of these files.

Now let s dive down into the other tags that you will find within the configuration files. If you wish to find more information about the attributes for each of these elements please refer to your .NET Framework documentation.

Table 6-1. Configuration File Tags
Tag	Description
<trace>	This element can help when you are trying to get more information about how your Web application is performing. It enables you to gather information about requests received by the Web server. (http://<servername>/<appname>/trace.axd.) Be sure to set this attribute to false when you deploy your Web application.
<globalization>	Specifies how Web requests and local searches are handled; for example, what language the requests are handled in.
<httpRuntime>	Controls parts of the ASP.NET and HTTP runtime engine, including attributes for number or requests before returning a 503, maximum size of incoming files and minimum number of threads that will be kept free for processing new requests.
<compilation>	One of the most extensive elements, which includes settings that determine how your code is compiled, such as debug. This will include debug information within the compiled assemblies. The debug attribute should be set to false when you deploy your Web application.
<pages>	Allows ways to configure the SessionState, ViewState and other settings that will enable you to get more out of your Web application.
<customErrors>	This element allows you to customize how your Web applications respond to errors in terms of what the user sees.
<authentication>	Allows you to choose the authentication mode you want to use.
<identity>	Allows your Web application to use impersonation.
<authorization>	Specifies accounts that are authorized to access resources.
<machinekey>	Specify keys for encryption and decryption of cookie data. However it can not be used at the subdirectory level.
<securityPolicy>	Allows the choice of several named security policies.
<trust>	Implements the security policy stated in the securityPolicy element.
<sessionState>	Used to configure the HttpModule element, mainly the state management to be used.
<httpHandlers>	Allows you to assign certain requests to different types of resources to handler classes. This can be used to limit the HTTP access to certain file types.
<processModel>	This setting deals with how the Web application is run and provides many features such as automatic restart and allowed memory size to help improve performance.
<webControls>	Allows the use of client-side implementations of ASP.NET server controls by specifying script files.
<clientTarget>	Allows you to use a single alias for your application.
<browserCaps>	Allows the application to gather information about the user s browser.

Understanding Your Web Application

Some of the configuration settings listed above have adverse effects on your Web application or even generate problems when you re creating test scripts for your Web application. For example, many people might find the <custom Errors> element in the Web.config file useful because you can set up a custom error page to redirect to when an error occurs. When you build a test script in ACT, by default you do not get a visual indication of what is displayed on the page. If an error occurs in your test script while recording, you could be redirected to the custom error page, which receives a 200 status code (success) according to the IIS log file. The page that had the error would only show a 302 (redirect) instead of the true error. So you must be careful and understand your application, otherwise you could waste a lot of time trying to solve the problem.

NOTE
If you see a large percentage of page views occurring on one page, verify in the Webconfig file to make sure it is not the Custom Error Handling file for your ASP.NET Web application.