Lesson 4: Maintaining a Deployed Application

Lesson 4: Maintaining a Deployed Application

After you have deployed a Web application, you need to monitor how it performs on the server. Many issues can crop up at this point because of the number of users accessing the application, the unpredictable nature of user interaction, and the possibility of malicious attack.

Maintaining a deployed application is an ongoing task that involves three major steps:

• Monitoring the application for error, performance, and security issues

• Repairing the application as issues are discovered

• Tuning the application to respond to user traffic

In this lesson, you ll learn how to perform these tasks, as well as learn about some optimization techniques.

After this lesson, you will be able to

• Use the Windows tools to monitor application errors, security, and performance on the server

• Create alerts to notify you when a problem occurs

• Chart performance and monitor activity using event logs

• Repair a deployed application by replacing the assembly or content files

• Use the server s configuration settings to control how ASP.NET applications maintain their processes

• Evaluate how programming techniques and ASP.NET features affect performance

Estimated lesson time: 20 minutes

Monitoring the Server

After your application is deployed, you need to monitor the server where it is running to help detect and correct problems related to security, performance, and unanticipated errors. Windows provides the following MMC snap-ins for monitoring security, performance, and error events:

• The Event Viewer snap-in

  Lists application, system, and security events as they occur on the system. Use this tool to see what is currently happening on the server and to get specific information about a particular event.

• The Performance snap-in

  Lets you create new events to display in the Event Viewer and allows you to track event counters over time for display graphically or in report form.

The following sections describe how to use these tools in more detail.

Viewing Events

Use the MMC Event Viewer snap-in to view application, system, and security events as they happen.

To run the Event Viewer, choose Event Viewer from the Administrative Tools submenu on the Windows Start menu. (You can show the Administrative Tools menu in Windows XP Professional by opening the Start button s Properties dialog box and clicking the Customize button on the Start Menu tab. The Administrative Tools option is located on the Advanced tab of the Customize Start Menu dialog box.) After clicking the Event Viewer shortcut, Windows displays the Event Viewer snap-in in the MMC, as shown in Figure 9-19.

Figure 9-19. Viewing events

The Event Viewer snap-in displays general application, system, and security events at three levels: informational events, warning events, and error events.

To view information about a specific event, double-click the event. The snap-in displays the Event Properties dialog box, as shown in Figure 9-20.

Figure 9-20. Viewing event details

You can use the Event Viewer to get a snapshot of what is happening on the server or to get details about a particular event. To create new events or to track events over time, you need to use the MMC Performance snap-in, as described in the following sections.

Defining New Events

In many cases, the standard system, application, and security events don t tell you what you really want to know. For example, you might want to know when the number of users connected to a Web application exceeds 1000 or when an unhandled exception occurs within the Web application. To add events such as these to your counter and trace logs, use the MMC Performance snap-in.

To run the Performance snap-in, choose Performance from the Administrative Tools submenu on the Windows Start menu. Windows displays the Performance snap-in, as shown in Figure 9-21.

Figure 9-21. Adding events to monitor

The Performance snap-in allows you to create log files that record activity on the server and to create alerts that raise events in the Event Viewer. Using this tool, you can monitor a wide variety of information about the server, the applications it is hosting, and the users connected to it.

Perhaps the best way to understand how this works is to walk through adding an event to monitor on your own system, as described in the following steps:

1. From the Performance window, select Alerts from the Performance Logs And Alerts list in the left pane.

2. From the Action menu, choose New Alert Settings. The snap-in displays the New Alert Settings dialog box, as shown in Figure 9-22.

   

   Figure 9-22. Naming a new alert

3. Type a name for identifying the alert, and click OK. The snap-in displays the new Alert dialog box, as shown in Figure 9-23.

   

   Figure 9-23. Setting alert properties

4. Add an event to monitor by clicking Add. The snap-in displays the Add Counters dialog box, as shown in Figure 9-24.

   

   Figure 9-24. Adding counters to monitor ASP.NET users

5. Select the hardware item or application to monitor from the Performance Object drop- down list. The snap-in updates the counters list with items that apply to the selected Performance object. Click Add to add the selected counter to the alert. Click Close when you ve finished.

6. Set the criterion that raises the alert in the new Alert dialog box by typing a number in the Limit box.

   For example, Figure 9-25 shows settings to raise the alert when the ASP.NET user count exceeds 1000.

   

   Figure 9-25. Setting a criterion to raise the alert

7. Click the Action tab to specify what the server should do when the alert is raised. By default, the server records the alert as an event that can be viewed from the Event Viewer. You can also send the alert as an e-mail or write the alert to a log file, as shown in Figure 9-26.

   

   Figure 9-26. Specifying the action to take

8. When you have finished, click OK. The snap-in adds the alert to the Alerts list, as shown in Figure 9-27.

   

   Figure 9-27. The new alert

By default, the snap-in starts monitoring the new alert immediately. You can stop or restart monitoring the alert by right-clicking the alert and choosing Stop or Start from the shortcut menu.

Windows raises the alert whenever the alert criterion is met. For some counters, such as error counts, this means that after the alert is raised the first time, it is raised after every interval. Because the error count is not automatically reset, it always exceeds the count limit when the limit is met. For these types of alerts, you should be careful what action you specify sending an e-mail in response to an error count alert can result in a lot of redundant mail messages.

Creating Event Logs

Defining a new event by creating an alert is a good way to be notified the moment a problem occurs or when a performance has degraded, but to track errors and performance over time, you must create an event log. Event logs let you gather information about a wide variety of events over time and then display that information graphically or in text form.

To create an event log, follow these steps:

1. From the Performance window, select Counter Logs from the Performance Logs And Alerts list in the console tree.

2. From the Action menu, choose New Log Settings. The snap-in displays the New Log Settings dialog box, as shown in Figure 9-28.

   

   Figure 9-28. Naming a new log file

3. Type the name of the log, and click OK. The snap-in displays the log file s properties dialog box, as shown in Figure 9-29.

   

   Figure 9-29. Setting log properties

4. Click Add Objects or Add Counters to add items to track within the log file. The snap-in displays the Add Counters dialog box, as shown in Figure 9-30. These counters work the same way they do for alerts.

   

   Figure 9-30. Adding counters to record

5. Click the Log Files tab to specify the format of the log file to create. The snap-in displays the Log Files properties, as shown in Figure 9-31.

   

   Figure 9-31. Specifying log file format

6. Log files can be saved in binary, text, or database formats. Click OK when you ve finished. The snap-in adds the log to the Counter Logs list, as shown in Figure 9-32.

   

   Figure 9-32. The new log

As with alerts, the snap-in starts monitoring the new log immediately. You can stop or restart monitoring the log by right-clicking the log and choosing Stop or Start from the shortcut menu.

Viewing Event Logs

By default, the Performance snap-in saves log files to the PerfLogs root folder. To view the log file from within the snap-in, follow these steps:

1. From the Performance window, select System Monitor from the console tree. The snap-in displays the system monitor with the current performance statistics, as shown in Figure 9-33.

   

   Figure 9-33. Current CPU, memory, and disk usage statistics

2. Click the View Log Data toolbar button. The snap-in displays the System Monitor Properties dialog box, as shown in Figure 9-34.

   

   Figure 9-34. System Monitor Properties dialog box

3. Select Log Files, and click Add to specify a file to open. The snap-in displays the Select Log File dialog box, as shown in Figure 9-35.

   

   Figure 9-35. Opening a log file

4. Select a log file to open from the PerfLogs folder, and click Open to add it to the monitor.

5. Click the Data tab in the System Monitor Properties dialog box to add items from the log to the chart, as shown in Figure 9-36.

   

   Figure 9-36. Adding items to chart

6. Click OK to close the System Monitor Properties dialog box. The snap-in displays the log file, as shown in Figure 9-37.

   

   Figure 9-37. Viewing a log file in chart form

7. Click the View Report toolbar button to view the data as text rather than graphically. The System Monitor displays the text view, as shown in Figure 9-38.

   

   Figure 9-38. Viewing a log file in report form

   More Info
   The MMC Event Viewer and Performance snap-ins provide a way to monitor the health of a server, detect application errors, identify resource conflicts, and predict future hardware needs. For more information about performing these tasks, see the online Help provided with each of these snap-ins.

Repairing Deployed Applications

After a Web application is deployed, you can revise and repair it in place, without restarting the server or IIS.

To repair a deployed Web application, copy the new assembly (.dll) and/or content files (.aspx, .ascx, and so on) to the application folder on the server. ASP.NET automatically restarts the application when you replace the assembly; you do not need to install or register the assembly on the server.

ASP.NET Web applications also have a limited ability to repair themselves through process recycling. Process recycling is the technique of shutting down and restarting an ASP.NET worker process (aspnet_wp.exe) that has become inactive or is consuming excessive resources. You can control how ASP.NET processes are recycled through attributes in the processModel element in the Machine.config file, as shown in boldface here:

<processModel enable="true"   timeout="Infinite"  idleTimeout="Infinite"   shutdownTimeout="0:00:05"  requestLimit="Infinite"  requestQueueLimit="5000"   restartQueueLimit="10"  memoryLimit="60"  webGarden="false"  cpuMask="0xffffffff"  userName="machine"  password="AutoGenerate"  logLevel="Errors"  clientConnectedCheck="0:00:05"  comAuthenticationLevel="Connect"  comImpersonationLevel="Impersonate"   responseRestartDeadlockInterval="00:09:00"  responseDeadlockInterval="00:03:00"  maxWorkerThreads="25"   maxIoThreads="25"/>

Table 9-4 describes the processModel attributes that relate to process recycling.

Table 9-4. Process Recycling Attributes

Attribute	Specifies
timeout	The amount of time (hh:mm:ss) before the process is shut down and restarted. Use this setting to automatically recycle a process after a certain number of requests as a preventive measure.
shutDownTimeOut	How much time each process has to shut itself down. After this amount of time, the process is terminated by the system if it still running.
requestLimit	The number of queued requests to serve before the process is shut down and restarted. Use this setting the same way you use the timeout attribute.
restartQueueLimit	The number of queued requests to retain while the process is shut down and restarted.
memoryLimit	The percentage of physical memory the ASP.NET process is allowed to consume before that process is shut down and a new process is started. This setting helps prevent memory leaks from degrading the server.
responseRestart DeadlockInterval	The amount of time to wait before restarting a process that was shut down because it was deadlocked. This setting is usually several minutes to prevent applications with serious errors from degrading the server.
responseDeadlockInterval	The amount of time to wait before restarting a process that is deadlocked. The process is restarted if there are queued requests and the process has not responded within this time limit.

Tuning Deployed Applications

ASP.NET Web applications have a number of settings you can control to tune performance after the applications are deployed:

• Use the processModel element s attributes in the server s Machine.config file to control the number of threads and the time-out behavior that the server provides for Web applications.

• Use the sessionState element s attributes in the application s Web.config file to control how Session state information is saved.

The following sections discuss each of these techniques.

Adjusting processModel Attributes

The processModel element in the server s Machine.config file provides attributes that control certain performance aspects, such as the maximum number of requests to be queued, how long to wait before checking whether a client is connected, and how many threads to allow per processor, as shown here in boldface:

<processModel enable="true"  timeout="Infinite"  idleTimeout="Infinite"  shutdownTimeout="0:00:05"  requestLimit="Infinite"   requestQueueLimit="5000"  restartQueueLimit="10"  memoryLimit="60"  webGarden="false"  cpuMask="0xffffffff"  userName="machine"  password="AutoGenerate"  logLevel="Errors"   clientConnectedCheck="0:00:05"  comAuthenticationLevel="Connect"  comImpersonationLevel="Impersonate"  responseRestartDeadlockInterval="00:09:00"  responseDeadlockInterval="00:03:00"   maxWorkerThreads="25"  maxIoThreads="25"/>

Table 9-5 describes the processModel attributes that relate to performance tuning.

Table 9-5. Performance Attributes

Attribute	Specifies
requestQueueLimit	The number of queued requests allowed before ASP.NET returns response code 503 (Server too busy) to new requests
clientConnectedCheck	The amount of time (hh:mm:ss) to wait before checking whether a client is still connected
maxWorkerThreads	The maximum number of threads per processor
maxIOThreads	The maximum number of I/O threads per processor

In general, lowering these settings allows your server to handle fewer clients more quickly. Increasing these settings permits more clients and more queued requests, but slows response times.

Adjusting sessionState Attributes

Storing state information for each client session takes time. If your Web application does not use Session state variables, you should turn off Session state tracking.

To turn off Session state, in the application s Web.config file, set the sessionState element s mode attribute to Off , as shown here:

<sessionState mode="Off" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;user id=sa;password=" cookieless="false"  timeout="20"  />

Turning off Session state means that you can t use Session state variables in code anywhere in the application.

Optimization Tips

Think of tuning as making adjustments to a deployed application that don t affect code. Optimization usually refers to writing code in a way that executes more quickly or consumes fewer resources. In general, optimizations simply reflect the good programming practices that you have learned so far in this book. Some of the most important points are summarized here:

• Turn off debugging for deployed applications.

  Code that has been compiled with release options runs faster than code compiled with debug options.

• Avoid round-trips between the client and server.

  ASP.NET uses postbacks to process server events on a page. Try to design Web forms so that the data on the Web form is complete before the user posts the data to the server. You can use the validation controls to ensure that data is complete on the client side before the page is submitted.

• Turn off Session state if it isn t needed.

  In some cases, you can design your code to use other techniques, such as cookies, to store client data.

• Turn off ViewState for server controls that do not need to retain their values.

  Saving ViewState information adds to the amount of data that must be transmitted back to the server with each request.

• Use stored procedures with databases.

  Stored procedures execute more quickly than ad hoc queries.

• Use SqlDataReader rather than data sets for read-forward data retrieval.

  Using SqlDataReader is faster and consumes less memory than creating a data set.

When applying these optimization tips, please be guided by good sense. For instance, if you need to retain data about a client session, go ahead and use Session state rather than write your own implementation to do the same thing.