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.

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).

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.

There are various logging modules and formats available with IIS. With the exception of the ODBC logging module, which is written to a database, all of the other log files are ASCII text files. The NCSA Common Log File Format and the Microsoft IIS Log Format are both fixed ASCII formats that are not customizable. We always use the W3C Extended Log File Format for our testing efforts because you can customize it by selecting the fields you want to monitor. From an administrative point of view this is very useful because you log less data, you can conserve more available disk space and keep your log files more readable without sacrificing functionality. All of the ASCII text-based modules discussed above can be set to create new logs when the file size reaches a certain threshold or timeframe (hourly, daily, weekly, monthly). We are not going into great detail about every available log file format in IIS, but we do discuss more information relating to the W3C Extended Log File Format because we use it for identifying problems in Web applications that we encounter.

By default the W3C Extended Log File Format uses Greenwich Mean Time (GMT) for times listed by each request, where all of the other formats use the local time. Keep in mind that the times listed in the log files are generated by the server after processing a request but do not reflect network travel time to the client or client processing time.

Below is a sample from one of our log files in the W3C Extended Log File Format. It is worth mentioning that we did not select every available field to be logged, but only the relevant fields for this Web application.

#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 2002-05-24 17:25:01
#Fields: date time c-ip cs-method cs-uri-stem cs-uri-query 
sc-status sc-bytes cs-bytes time-taken 
2002-05-24 17:25:01 181.39.207.242 GET /storevbvs/default.aspx - 
200 12893 373 2516

The first four lines of a properly formatted W3C Extended log, which begin with a pound sign (#), contain directives or header information such as the version of the log file format, the date and time the file was created, and field identifiers for various information which is logged for each entry. The field identifiers are prefixed in Table 6-2.

Table 6-3 contains a complete list of available properties, definitions, and reference information for each field in the W3C Extended Log File Format.

Logging is enabled within IIS by default and can be disabled at the site, directory, or file level by right-clicking the element and clearing the Log Visits checkbox in the IIS MMC snap-in Properties dialog box, as shown in Figure 6-1.

Figure 6-1. Clearing the Log Visits checkbox

Disabling logging on certain directories that contain static or rarely changing files is another useful method of reducing your Web server log file size and saving valuable disk space. For example just by browsing the IBuySpy Web application home page http://localhost/storevbvs/Default.aspx, you write 16 different entries in the IIS log file for that one request. Fourteen images, one style sheet, and the actual Default.aspx page are referenced in the code. Keep in mind that as far as the user is concerned, it is only one URL request, even though it’s several HTTP requests to the Web server (one request for Default.aspx, one for the style sheet, and 14 for the images). You can imagine how large the log file can grow and how much disk space can be consumed from a stress test script that requests multiple pages using several browser connections for an extended period of time.

There are several ways to verify how many items are referenced by a page and the size of each file. One such method useful in checking a single page is to first clear your browser cache and then request the page from your browser. You should see all of the different file elements referenced from the page from that one request. Add up the total number of file elements and their file size by viewing the file properties. This is a tedious method when you have many files to investigate. An alternative method that makes more sense to use when you have several files is to use a log parser and view the results in a report format. There are several commercial log parsers available today.

Now that we have presented some background information on what to look for in the log file let’s look at a somewhat real-world example of how to use the IIS log file to quickly identify errors occurring on the Web tier. The next four steps are necessary for us to demonstrate this example.

The results of the script playback from the IIS log file are as follows:

#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 2002-05-30 18:36:11
#Fields: date time c-ip cs-method cs-uri-stem cs-uri-query 
sc-status sc-bytes cs-bytes time-taken 
2002-05-30 18:36:11 181.39.207.242 GET 
/storevbvs/Default.aspx - 200 0 346 15
2002-05-30 18:36:18 181.39.207.242 GET 
/StoreVBVS/productslist.aspx CategoryID=20&selection=2 200 0 377 7016
2002-05-30 18:36:18 181.39.207.242 GET 
/storevbvs/Default.aspx test=count 200 0 357 16

Note that there are three requests in the above log. The first thing you should look for is to verify that the requests were successful and there were no errors generated. This is accomplished by looking at the field labeled sc-status, also known as the status code. Table 6-4 below is a useful table to reference HTTP status codes.

All three of the log entries are GET requests (indicated by the method) and they appear to be successful with 200 status code. Also, there appears to be very little data transferred (indicated by the Bytes Sent and Received fields). The ASPX execution time or the Time Taken field for the Default.aspx page was quick, but the ProductList.aspx took over seven seconds (7016 milliseconds, to be exact). Voilà, we have identified a problem. The IIS logs are very useful in helping you to identify pages that are executing slowly, transferring a lot of data and identifying errors in your Web application. Now that we have successfully identified a problem at the page level, we will discuss a new feature available in ASP.NET that will help us to trace the problem down to the line of code causing the delay.

After the files with high execution times are identified from the IIS logs, we typically add several timers throughout the page to pinpoint the slowly executing code. When the page is requested the timers are written to a text file using the local file system of the Web server. Finally, you simply open the text file to view the timer information that was written between each block of code separated with a timer. Below is an example written in VBScript to illustrate this point.

<% Dim t1, t2
  ’Timer 1 – start timer for section 1
 t1=Timer
%>
INSERT CODE BLOCK HERE
<% ’Timer 2 – start timer for section 1
 t2=Timer
‘The following code can be placed at the end of the ASP file.
Dim fso, filename, fileref
filename =  "C:	emp" + cstr(Timer) + ".txt"
‘A new file is created each time the page is executed. 
SET fso = createobject("Scripting.FileSystemObject")
SET fileref = fso.createtextfile(filename  )

‘Write timer values to the file – time is in milliseconds.
fileref.writeline("1," + cstr(t1) + "," + cstr(t2) + "," +  cstr(t2-t1))
‘Close the file.
fileref.close
%>

Another method for finding slowly executing code within traditional ASP pages is to first make a note of how long it takes the page to execute without modifying the code. Then place the Response.End method at different places within your code and request the page again noting the execution time. The Response.End method stops the execution of the code so you can compare the time against the time taken from the original request. This method often takes several tries to identify the culprit and might end up generating errors, because you are not executing the code in its entirety.

Tracing in ASP.NET can be performed at either the page or application level. Page-level tracing is implemented by adding Trace="True” to the @ Page directive at the top of an ASPX file. The complete syntax is as follows:

<%@ Page  Trace="True"%>

This will append an HTML table to the browser once the original content has rendered. The HTML table will contain detailed information on the request itself: timing information, server control tree (with rendering viewstate size), header, cookies, querystring along with form parameters, server variables, and of course, the ability to add custom messages. The syntax to add custom tracking information is Trace.Write() or Trace.Warn(). Both methods create the same output but Trace.Warn() writes the output in red text.

Enabling tracing at the application level is accomplished by adding or modifying the following statements to the Web.config file.

<configuration>
    <system.Web>
         <trace enabled="true"
            requestlimit="15"
            pageOutput="true"
            traceMode="SortByTime" 
            localOnly="true"/>
    </system.Web>
</configuration>

After trace is enabled in the Web.config file, you can view the results of various requests by browsing to a special HttpHandler (Trace.axd) to view the output. The requestLimit parameter will control the number of requests to log for which trace information will be collected. You should also be aware that page-level tracing will override application-level tracing.

Let’s take the above example, in which we used the IIS log file to identify a slow executing page, a step further and use the new Trace method discussed above to isolate the code that is causing a delay in our ProductList.aspx page.

You should notice similar information displayed in the HTTP Handler (Trace.axd) compared to what we saw previously in the IIS log file. We already identified the ProductList.aspx page as the problematic page because it is taking more than seven seconds to load. Now click the View Details hyperlink for the ProductList.aspx page.

Because we used Trace.Warn the code we added should immediately stand out when you look at it online because the syntax is in red text. In Figure 6-3 below you can identify the code we added under the Trace Information heading and the Find Delay Category. From the Timer 1: Begin message to the Timer 1: End, it took around seven seconds to execute the code between the two statements we added. Voilà! Once again we successfully pinpointed the problem causing the delay. Now, you can verify that this is the problem by simply commenting out the suspected line of code and browsing directly to the ProductList.aspx page. The execution time should be reduced by seven seconds, indicating that indeed this was the problem causing the delay.

Figure 6-3. The problem code is in red text.

In the following sections, we discuss the IIS counters and ASP.NET performance counters that our team uses in performance testing.

There are two sets of performance counters in ASP.NET that can be used in diagnosing and monitoring Web application performance. They reside under ASP.NET, and ASP.NET application performance objects. If you have multiple versions of ASP.NET installed, there may be multiple instances of these counters, each with a version stamp on them. The names without versions will always give you performance data for the highest version installed on the machine.

Traditionally application variables were used to store information like connection strings or as a caching mechanism for storing variables and recordsets among multiple users requests. They still exist in ASP.NET but many of the functions previously served in traditional ASP have been replaced with newer more effective methods. Use the Web.config file to store and retrieve database connection strings or use a trusted connection with a SQL server. Utilize the new caching engine discussed below to store frequently accessed data. Application state still has the limitation and cannot be shared across multiple Web servers.

Session information is data stored in memory of the Web server for each user making a request. In the past, many problems have been associated with enabling and using session state within a Web application. The underlying protocol used in making each request (HTTP) is stateless, so to overcome this in traditional ASP Web applications an HTTP cookie was assigned to the client and would be passed back to the server for subsequent requests within a certain time frame. For a Web application located on multiple machines or a Web farm, the user may be redirected to a different machine between requests and the session cookie would be lost because it could not be passed among multiple machines.

ASP.NET addresses some of the scalability issues previously associated with using session data in Web farms by offering the option to store it out-of-process in a Windows service or to store it in a SQL server. Keep in mind that scalability is gained but there is a performance hit associated with running the session out-of-process. Session state is enabled by default in the Machine.config file and is set to run in-process. Running Session InProc has the same limitations for ASP.NET Web applications as discussed above for traditional Web applications, however it is the fastest most efficient method to use if session state is required. Our recommendation is if you do not absolutely have to use session state, then disable it in the Web.config file or at the page level. You can disable it at the page level by using <%@ Page EnableSessionState = “False” %>.

The ASP.NET output cache can use memory on the server to store the output of processed and rendered pages. If output caching is enabled, the output of a page is saved after the first request. Subsequent requests for the same page are then retrieved from the cache, if the output is still available, and returned to the user bypassing all the overhead of parsing, compiling and processing. This greatly improves the response time and reduces utilization of the server’s resources.

This feature can easily be enabled for pages by including the OutputCache directive within the page. For example, to save the output of a processed page for a maximum of 60 seconds, using the most basic syntax, you can include the following directive in the page:

    <%@ OutputCache Duration="60" VaryByParam="None"%>

The Duration and VaryByParam attributes are required.

For pages that are short lived but have potentially expensive-to-obtain data, it may be better to utilize the Cache object to cache and update the data as needed (see the section on “Cache API” below). The VaryByParam attribute allows you to save multiple versions of a page. For example, pages can be designed to produce varying output based on the values of the parameter sent. Specifying a value of None for the VaryByParam attribute saves the output for the page if it is accessed without any parameters. To save versions of the page for all combinations of parameters, you can pass a value of *. You must, however, be aware that caching multiple versions of a page will consume additional memory. To cache output based on a specific querystring parameter or form field within the page, you can specify the name of the parameter. Multiple parameters can be included by separating them with a semicolon. For example, if a page has a form with ProductCategory and Product fields, you can cache the output based on values supplied for these parameter with the following syntax:

<%@ OutputCache Duration="10" VaryByParam="ProductCategory;Product"%>

Besides the two required attributes that are supported by the OutputCache directive, there are three additional attributes all of which are optional; these are Location, VaryByCustom, and VaryByHeader. The Location attribute controls where the data will be cached (for example, the server or client). VaryByHeader can cache based on specific headers sent with the request, and VarybyCustom can be used to cache based on browser type when specified with a value of Browser or can be used to implement custom logic when supplied with any other value.

Fragment caching is similar to output caching in the sense that the directive is the same. This level of caching is used to cache portions of a page that are implemented as user controls and is also referred to as partial page caching or user controls caching. Fragment caching should be considered whenever there is a lot of information to cache and caching at the page level is prohibitive in terms of server memory and cache utilization. Again, as with output caching, fragment caching is best used to cache output that does not vary tremendously or for output that is resource intensive.

The Output directive to implement fragment caching has to be included as part of the file implementing the control. The Duration and VaryByParam attributes are required and are exactly the same as in output caching. Additionally, there is the VaryByControl attribute, which is specific to fragment caching and can be included only in the user control file.

    <%@ OutputCache Duration="60" VaryByParam="None"%>

The caching API lets you save any piece of information in server memory that you want to reuse. For example, let us say that you need to display the product categories on a page in addition to other information. Rather than retrieving this information from the database with every request to the page, you can save the categories via the caching API. The most basic syntax to cache something is:

Cache("mydata"}() = "some data"

You can store entire data sets besides just strings and numeric data. Retrieving the cached data is just as simple:

X = Cache("mydata")

Other useful methods to be aware of are the Remove method, used to remove an item from the cache and the Insert method to add items to the cache. The syntax for the Remove method is:

(Cache.Remove("mydata"))

The Insert method is an overloaded method of the Cache object and has several versions. For example, the following version of the Insert method can be used to add an item to the cache with no external dependency and with an absolute expiration time of 120 minutes from the first time the page is cached:

Cache.Insert("mydata", mydata, nothing, _
            DateTime.Now.AddMinutes(120), TimeSpan.Zero)

The last parameter in the previous example is known as the sliding window and can be used to set an expiration for a cached item relative to the time the item was first placed in or last retrieved from the cache The sliding value parameter can be thought of as the maximum length of time between successive calls that need to elapse before a cached item is removed from the cache. For example, to place an item in the cache for a maximum of 10 minutes between successive retrievals, you can use the following syntax of the Cache object’s Insert method:

Cache.Insert("mydata", mydata, nothing, DateTime.MaxValue, _
            TimeSpan.FromMinutes(10))

The first step in communicating with the data tier is to establish a connection with the database server. The SQL Server .NET Data Provider gives us the SqlConnection object for this purpose. Creating a connection is fairly straight forward; the following VB.NET sample code demonstrates opening a connection to the SQL server on the local machine and connecting to the Pubs database:

Dim strCnStr As String = "Data Source =.;" _
             & "Integrated Security=SSPI;" _
             & "Initial Catalog = Pubs"
Dim objCn as New SqlConnection(strCnStr) _
    objCn.Open()

By default, this data provider takes advantage of connection pooling. This helps reduce the overhead of establishing a connection each time it is requested because all of the work is done up-front when the first connection is established. It is important, to understand when this feature is taken advantage of. For a pooled connection to be utilized, the connection strings of all new connections has to match that of the existing pooled connections exactly. Even an extra space in the string will cause the .NET runtime environment to create a separate pool. In fact, the .NET runtime creates a separate connection pool for every distinct connection string. This implies that connections utilizing different usernames and password will fail to take advantage of pooled connections.

The other factor that determines whether a pooled connection is utilized is the transaction context. A second connection will use a pooled connection as long as the transaction context is the same as the initial connection or does not have one at all.

Controlling the size of the connection pool is affected by specifying the min and max properties. This is important if you need to control the amount of memory utilized at the Web tier. If all pooled connections are active, any extra connection request will be blocked until one is relinquished or the connection time out has expired (the default is 15 seconds). The following code demonstrates setting these properties as part of the connection string:

Dim strCnStr As String = "Data Source =.;" _ 
             & "Integrated Security=SSPI;" _
             & "Initial Catalog = Pubs;" _
             & "Min Pool Size=10;" _
             & "Max Pool Size =100"

Another property that can have an effect on performance is the packet size. For applications that transfer large blob or image fields, increasing the packet size can be beneficial. In cases where the amount of data transferred is small, a smaller value for the packet size may be more efficient. The following code demonstrates setting this property as part of the connection string:

Dim strCnStr As String = "Data Source =.;" _ 
             & "Integrated Security=SSPI;" _
             & "Initial Catalog = Pubs;" _
             & "Packet Size=32768"

A common scenario for Web applications is the retrieval/modification of data from the data source. The SQL Server .NET provider implements the SqlCommand/DataReader and the DataAdapter /DataSet classes that allow the user to retrieve/modify the data. We only briefly discuss the SqlCommand/DataReader in this book; information on the SqlDataAdapter/DataSet classes can be obtained from other sources that deal specifically with ADO.NET.

The SqlCommand/DataReader is connection oriented and provides certain methods that can be leveraged to improve application performance. These methods include the ExecuteNonQuery, ExecuteScalar and ExecuteReader. Additionally the SqlCommand class implements the ExecuteXmlReader method for data returned in XML format. A description of these four methods along with an example (VB.NET Console application) for each follows. The examples make a connection to the NorthWind database, which by default is installed with Microsoft SQL Server.

Imports System
Imports System.Data
Imports System.Data.SqlClient

Module ExecuteNonQuery

    Sub Main()
        Dim strConnString As String = "Data Source=.;" _
                & "Initial Catalog=Northwind;" _
                & "Integrated Security=SSPI"
        Dim strSQL As String = "GetNumberOfCustomers"
        Dim sqlConn As New SqlConnection(strConnString)

        Dim sqlComd As New SqlCommand(strSQL, sqlConn)
        sqlComd.CommandType = CommandType.StoredProcedure
        sqlComd.Parameters.Add(New _
            SqlParameter("@i", SqlDbType.Int))
        sqlComd.Parameters(0).Direction = _
            ParameterDirection.ReturnValue

        sqlConn.Open()
        sqlComd.ExecuteNonQuery()
        sqlConn.Close()

        Console.WriteLine("Number of customers = {0}", _
            CType(sqlComd.Parameters(0).Value, Integer))
    End Sub
End Module

Imports System
Imports System.Data
Imports System.Data.SqlClient

Module ExecuteScalar

    Sub Main()
        Dim strConnString As String = "Data Source=.;" _
                & "Initial Catalog=Northwind;" _
                & "Integrated Security=SSPI"
        Dim strSQL As String = "select count(*) from customers"
        Dim sqlConn As New SqlConnection(strConnString)
        Dim sqlComd As New SqlCommand(strSQL, sqlConn)

        sqlConn.Open()
        Dim o As Object= sqlComd.ExecuteScalar()
        sqlConn.Close()

        Console.WriteLine("Number of customers = {0}", _
            CType(o, Integer))
    End Sub
End Module

Imports System
Imports System.Data
Imports System.Data.SqlClient
Imports Microsoft.VisualBasic

Module ExecuteReader

    Sub Main()
        Dim strConnString As String = "Data Source=.;" _
                & "Initial Catalog=Northwind;" _
                & "Integrated Security=SSPI"
        Dim strSQL As String = _
            "select customerid,contactname,phone from customers"
        Dim sqlConn As New SqlConnection(strConnString)
        Dim sqlComd As New SqlCommand(strSQL, sqlConn)

        sqlConn.Open()

        Dim sqlDR As SqlDataReader = _
            sqlComd.ExecuteReader(CommandBehavior.CloseConnection)

        Do While sqlDR.Read()
            Console.WriteLine(sqlDR("customerid").ToString() _
                & ControlChars.Tab _
                & sqlDR.GetSqlString(1).ToString() _
                & ControlChars.Tab _
                & sqlDR.GetSqlString(2).ToString())
        Loop

        sqlDR.Close()
    End Sub

End Module 

Dim sqlDR As SqlDataReader = _
    sqlComd.ExecuteReader(CommandBehavior.SingleRow);

Imports System
Imports System.Data
Imports System.Data.SqlClient
Imports System.Xml

Module ExecuteXmlReader

    Sub Main()
        Dim strConnString As String = "Data Source=.;" _
                & "Initial Catalog=Northwind;" _
                & "Integrated Security=SSPI"
        Dim strSQL As String = "SELECT customerid," _
                     & "contactname," _
                     & "phone " _
                     & "From customers " _
                     & "FOR XML AUTO"
        Dim sqlConn As New SqlConnection(strConnString)
        Dim sqlComd As New SqlCommand(strSQL, sqlConn)

        sqlConn.Open()

        Dim xmlR As XmlReader = sqlComd.ExecuteXmlReader()

        Do While xmlR.Read()
            Console.WriteLine(xmlR.ReadOuterXml())
        Loop

        xmlR.Close()
        sqlConn.Close()
    End Sub

End Module

Scaling out your Web tier is adding extra Web servers to your application to overcome a bottleneck or limitation caused by this tier. The benefit of scaling out your Web tier is an increase in throughput, provided there are no network, SQL, or other bottlenecks external to your Web server. The downside of scaling out is that it can be expensive in terms of hardware cost, software cost, and production support cost (power, rack space, cooling, and so on). Additionally, this puts more of a burden on support staff and deployment.

Scaling up your Web tier means adding extra hardware like memory and CPU capacity to your servers to overcome a bottleneck or limitation caused by this tier. This method is less expensive then scaling out because memory and CPU costs are relatively inexpensive compared to buying the whole machine. However, this approach may not give you linear gains in performance. To justify scaling up, performance testing is required both before and after scaling up to determine the overall impact.

Performance tuning is simply fixing bottlenecks on your application to achieve your desired throughput rate or response time criteria. In other words, fix the code instead of scaling your hardware. This method can be the most expensive if not performed during the software development life cycle, because it involves high labor cost for software developers, test engineers, and support engineers.

Microsoft’s implementation of a software-based load balancing solution is called Network Load Balancing (NLB). Using NLB is typically the least expensive method of load balancing and uses services bundled in Windows 2000 Advanced Server, Windows 2000 Data Center Edition, and Windows .NET Server. This method is good for most Web applications and allows you to scale out several nodes in your Web tier. For detailed instructions and implementation practices visit http://www.microsoft.com.

A hardware-based load balancing solution is optimal because it is a layer separate from your Web application’s code, so it does not use resources from your Web server. Many companies, such as Cisco, F5 Labs, and Extreme Networks, provide hardware-based load balancing products and solutions. For detailed information on configuring and installing a load balancing solution, visit the Web sites of the vendors listed above.