|
This Issue
This article is a reprint of chapter 16, by Nelson Howell , in a new book called 'Using Microsoft Internet Information Server 4' from Que Education & Training (ISBN 0789712636) due for publication in early March 1998. This chapter covers understanding and planning for server-side loading with the Internet Information Server version 4.0. Including determining load using performance monitor, using event viewer to discover errors, using TCP/IP troubleshooting utilities, configuring ODBC loads and understanding IIS logging.
Road Map
Determining Load Using Performance Monitor
Performance Monitor is used to monitor and log activity on your server. It measures hardware and software on the server. The counters included in Windows NT enables you gather necessary information about our server.
Using Event Viewer to discover errors
The Event Viewer will log and display information about errors, configuration, security, user and environment changes. The Event Viewer provides you with information about your server to determine loads.
Using TCP/IP Troubleshooting Utilities
The TCP/IP protocol suite includes many tools that will assist in troubleshooting of server connectivity issues.
Configuring ODBC loads
Database connectivity and configuration are important issues. performance may be affected when using ODBC is used for database connections.
Understanding IIS Logging
IIS logging provides records of activity on your server. The data collected in the IIS logs, provides information on the number of visitors, most popular sites, trouble URL's and general traffic.
Understanding and planning for server-side loading is an integral part of effectively planning and implementing an Internet server. It involves an in-depth understanding of the performance of the components that make up your Web server. This includes the physical components where IIS is running to the back-end processes that provide database functionality and the network on which it operates. In this chapter, we will cover the use of some of the following tools to make your job easier.
Internet Information Server has many built in server-side components. They range from Active Server Pages (ASP) to database connectivity. Server-side loading however, is not limited to only these specific server-side components. It includes replication and back-end database functionality that provide the real-time reading and writing of data to the database.Microsoft Active Server Pages (ASP) is server-side scripting that runs on the server rather than on the client or Internet browser. It is used to create and run dynamic Web server applications. ASP applications allow for the server to generate and send the Hypertext Markup Language (HTML) pages to the requesting client. ASP makes it easy for the developer to concentrate on delivering content based on the message to be communicated rather than customize content for different Internet clients. With this, however, comes a performance price. We will explore some of those performance issues involved with ASP and how to fine-tune them.
Server-side loading allows for the provision of load balancing over a number of resources. It enables each component to work independently and allow seamless integration. This enhances performance by relieving local resources that could create bottlenecks on a server. Load balancing is not an exact science because each solution is different. Windows NT, however, includes some useful tools to help you collect and examine performance statistics for your server. We will provide you with some methods and tools for determining the optimal performance for your Internet solution.
Planning allows you to proactively prepare by understanding and logging the performance of your resources. The key to understanding how your server works under specific load conditions includes a performance baseline with which to guide yourself.
Performance tuning for IIS can be done with the Microsoft Management Console (MMC). By selecting the Default Web Site in the MMC, you can select the Action drop-down menu, then select the Properties menu item to display the Default Web Site Properties dialog box. There you will see the Performance tab where you can tune Your Web Site Performance Based on the Number of Hits Expected per Day on the slide bar. Additionally, you can enable bandwidth throttling. Bandwidth throttling allows you to limit the bandwidth in Kbytes per Second (K/s) available to your Web site. Determining the optimal performance figures for your site is greatly dependent on your particular configuration. You can use the performance counters outlined in the next section to figure out your server's limitations.
You also must keep an eye on fault tolerance and load balancing. Fault tolerance means that if a server stops working, another server immediately can pick up the load with minimal or no disruption to users. Load balancing means that two or more servers can support large amounts of activity by distributing the load. It is possible to configure servers for both load balancing and fault tolerance through replication.
True replication is a process where the content or data is a mirror of the source and destination. While Windows NT provides a method to perform directory replication, it is not designed for large amounts of data transfer. You can, however, use the Robocopy (Robust File Copy) utility included with the Microsoft Windows NT Server Resource Kit. In IIS 4.0, replication and clustering can be achieved with Microsoft Content Replication System and an IIS included utility called iissync.exe. The Iissync.exe replicates IIS configuration settings. Clustering is when two or more servers work in tandem. Should one server fail, the remaining server(s) continue to function as a single unit without any interruption to the client.
Determining Load Using Performance Monitor
Microsoft Windows NT 4.0 Workstation and Server include the Performance Monitor and can be used to view, chart, and log performance statistics about your server components. The Performance Monitor is a graphical tool that enables you to gather data by defining the components you want to track and gather usage statistics by computer, object, counter, and instance (Figure 16.1) as follows:
Click Here For Figure
FIG. 16.1
Items added to a Performance Monitor Chart.
Computer
This defaults to the local computer and describes the computer on which Performance Monitor will track data. You can specify another computer on your network by typing the UNC (Universal Naming Convention) connection to that computer. For example, if you want to connect to a computer on your network named MyPC, you would type in Error! Bookmark not defined.
Object
This is used to select an object that can be monitored on the selected computer. Some objects, such as disk counters, are not enabled by default and must be enabled before they can be measured with Performance Monitor.
Instance
Every object has an instance of an object that is monitored. In the case of multiple processors, hard disks, and network cards, each object can have multiple instances if there are more than one of the particular objects installed and recognized by Windows NT.
Counter
Every object has a counter that is used to track or gather specific information about that object. These are very useful in determining where your server bottlenecks are occurring. If you are in doubt on which counter to start with, Microsoft has pre-selected the most common counters to help get you started.
Disk performance counters are not enabled by default. To enable disk performance counters, you must run diskperf -y from a command prompt. You then see the following message:
Disk Performance counters on this system are now set to start at boot. This change will take effect after the system is restarted.
Performance Baselines
The first step for determining your server load is to create performance baselines. I have outlined some useful counters to help get you familiarized with the specific counters for each object.
Creating a performance baseline is simply determining what your performance objectives are and recording those counters[md]that is, what performance counters you want to log and monitor.
There are four methods for tracking the performance counters on your server as follows:
Chart
The Chart view is the default view for Performance Monitor. There are two modes for the Chart view: Graph or Histogram. Both allow you to view the multiple data collected in real time. The Graph view displays the information in a linear display over time. The Histogram allows you to the collect counter data.
Alert
The Alert enables you to create alerts based on performance counter thresholds. Alerts are very useful in tracking real-time problems. If you want to keep an eye on a specific counter that you believe is creating a problem, the alert can be configured to send an administrative alert to you, switch to the Alert view, or log an event to the application in the Event Viewer.
Log
The Log view enables you to save logged performance counter data for future reference or as baseline performance. To create a log, select Log crtl+l from the View menu in Performance Monitor. Then select the Add to Log crtl+i from the Edit menu. The Log view allows you to create a log for objects rather than specific counters. Although the data might not be as detailed, it can give you a bird's-eye view of what kind of performance your server is delivering.
Report
The Report view enables you to log performance counter data in a report format. Each object is clearly reported in sections with each monitored counter for that object in that particular object section. This is especially useful when attempting to monitor a large number of counters.
Monitoring and Logging Performance Data
The key to successful server side load balancing is monitoring and logging performance data. It is not enough to monitor the performance but you must also log it. Let's say, for instance, that your Web server has been running at peak performance. Last week, you added a software component. This week, you configure a different component. Your server now runs as slow as molasses. This is so true of many issues that plague administrators. Where do you go from here? Had you taken the time to establish logs of those items you configured and then log the counter performance for items that might be affected by that configuration change, you could very easily consult your data and most likely find a pattern or solution to the performance problem.
Which object or counters do I monitor, you ask? That answer depends on what role your server plays. Is your server serving simple HTML pages to the Internet or an Intranet? Does your server provide FTP access? Is your server included in a plan to provide load-balancing or redundancy? Can your server handle the load? What type of network are you configured for? What are its limitations? What is the best time to replicate data? These are all valid questions that Performance Monitor can help you answer. The following section lists useful counters.
IIS Monitoring Counters
Internet Information server includes many counters that can be logged using Performance Monitor. I have included a list of those counters that are broken down into specific areas. These counters cover a wide range of functionality in IIS. The counters monitor activity from specific objects, services and/or server resources. They are as follows:
- Bandwidth usage counters
- Counters relating to caching
- Web site monitoring counters
- Throughput counters
- Request and errors counters
- User and connection counters
Bandwidth Usage Counters
Bandwidth usage counters provide you with data related to the amount of traffic your server or website is experiencing. Bandwidth usage counters can give you an excellent view of the bandwidth utlization over a period of time. Here is a list of those counters:
Web Site Monitoring Counters
Web site monitoring counters monitor the activity of specific objects and services. Web site monitoring counters monitor web site activity that varies over time. You can log the number of connections or connections dropped due to limited bandwidth throttling.
Bandwidth Usage Counters
Bandwidth usage counters provide you with data related to the amount of traffic your server or Web site is experiencing. Bandwidth usage counters can give you an excellent view of the bandwidth utlization over a period of time. Table 16.2 is a list of those counters.
Table 16.2[em]Bandwidth Usage Counters
|
Counter
|
Description
|
|
Current Blocked Async I/O Requests | Current requests temporarily blocked by bandwidth throttling settings. |
|
Measured Async I/O Bandwidth Usage | Measured bandwidth of asynchronous I/O averaged over a minute.
|
|
Total Allowed Async I/O Requests | Total number of requests allowed by bandwidth throttling settings counted from service startup.
|
|
Total Blocked Async I/O Requests | Total number of requests temporarily blocked due to bandwidth throttling settings, counted from service startup.
|
|
Total Rejected Async I/O Requests | Total requests rejected due to bandwidth throttling settings counted from service initialization.
|
Throughput Counters
Throughput counters monitor the rate at which data is sent and received by your server or Web site. Singular Webs can be monitored or the entire server can be monitored by selecting _total for object, Web service in Performance Monitor. The items that can be measured are listed in Table 16.3.
Table 16.3 Throughput Counters
|
Counter | Description |
|
Bytes Received/Sec | The rate that data bytes are received by the Web service.
|
|
Bytes Sent/Sec | The rate at which data bytes are sent by the Web service.
|
|
Bytes Total/Sec | The sum of Bytes Sent per second and Bytes Received per second. This is the total rate of bytes transferred by the Web service.
|
|
Files/Sec | The rate that files are transferred. Includes files sent and received by the Web service. |
|
Files Received/Sec | Rate at which files are received by the Web service.
|
|
Files Sent/Sec | The rate that files are sent by the Web service. |
|
Total Files Sent | The total number of files sent by the Web service counted from service startup.
|
|
Total Files Transferred | The total of files sent and received
|
|
Requests and Errors Counters | Request and Errors Counters log specific request types. Included are HTTP GET requests or CGI requests. Errors that are monitored are not-found errors. Singular sites can be monitored or the entire server by selecting _total for object, web service in Performance Monitor.
|
| CGI Requests/Sec | The rate of CGI requests that are simultaneously being processed by the Web service.
|
|
Current CGI Requests | The current number of CGI requests that are simultaneously being processed by the Web service.
|
|
Current ISAPI Extension Requests | This is the current number of extension requests that are simultaneously being processed by the Web service.
|
|
Delete Requests/Sec | The rate of HTTP requests using the DELETE method. |
| Get Requests/Sec | The rate of HTTP requests using the GET method. |
|
Head Requests/Sec | The rate that HTTP requests using the HEAD method. Head requests generally indicate a client query to check a document that the client has already downloaded to see if a refresh is needed.
|
| ISAPI Extensions Request/Sec | The rate that ISAPI Extension requests are being processed by the Web service.
|
| Maximum CGI Requests | The maximum number of CGI requests simultaneously processed by the Web service.
|
|
Maximum ISAPI Extension Requests | Maximum number of Extension requests simultaneously processed by the Web service.
|
|
Not Found Errors/Sec | Rate of errors due to requests that couldn't be found. These are generally reported as an HTTP 404 error code to the client.
|
|
Other Requests Methods/Sec | The rate that HTTP requests are made that don't use the GET, POST, PUT, DELETE, TRACE, or HEAD methods. These can include LINK or other methods supported by gateway applications.
|
|
Posts Requests/Sec | The rate at which HTTP requests using the POST method are made. Post requests are generally used for forms and/or gateway requests.
|
|
Put Requests/Sec | The rate that HTTP requests using the PUT method are made.
|
|
Total CGI Requests | Total Common Gateway Interface (CGI) requests. These are custom gateway executables (.exe) that an administrator can install to add custom form handling or other dynamic data configuration. CGI requests spawn a process on the server and can become a large drain on server resources.
|
| Total Delete Requests | The total number of HTTP requests using the DELETE method since service startup.
|
|
Total Get Requests | The total number of HTTP requests using the GET method from service startup. Get requests are generally used for basic file retrievals.
|
| Total Head Requests | The total number of HTTP requests using the HEAD method, counted from service startup.
|
|
Total ISAPI Extension Requests | Custom gateway Dynamic Link Libraries (.dll) that an administrator can install to add forms processing or other dynamic data sources. Unlike CGI requests, ISAPI requests are simple calls to a DLL library routine and thus are better suited for high performance gateway applications.
|
Total Method Requests | The number of HTTP GET, POST, PUT, DELETE, TRACE, HEAD, and other method requests counted from service initialization.
|
|
Total Method Requests/Sec | The rate which HTTP requests using GET, POST, PUT, DELETE, TRACE, or HEAD methods are made.
|
|
Total Not Found Errors | The number of requests that couldn't be found by the server. These are generally HTTP 404 error code.
|
|
Total Other Request Methods | The number of HTTP requests that are not GET, POST, PUT, DELETE, TRACE, or HEAD methods, counted from service initialization. They can include LINK or other methods supported by gateway applications.
|
|
Total Post Requests | The number of HTTP requests using the POST method counted from service initialization. Post requests are generally used for forms or gateway requests.
|
|
Total Put Requests | The number of HTTP requests using the PUT method counted from service initialization.
|
|
Total Trace Requests | The number of HTTP requests using the TRACE method counted from service initialization. Trace requests allow the client to see what is being received at the end of the request chain and use the information for diagnostic purposes.
|
User and Connection Counters
User and connection counters monitor user and connection activity rates. These monitors are useful when trying to determine the number and types of connections established to your server or site. Singular sites can be monitored or the entire server by selecting _total for object, Web service in Performance Monitor. Table 16.4 lists the user and connection counters.
Table 16.4 User and Connection Counters
| Counter | Description |
| Anonymous Users/Sec | The rate at which users are making anonymous connections to the Web service. |
| Connection Attempts/Sec | The rate at which connections using the Web service are being attempted. |
| Current Anonymous Users | The number of users that currently have an anonymous connection using the Web service. |
| Current Connections | Current number of connections established with the Web service. |
| Current Non-Anonymous Users | Current number of users who currently have a non-anonymous connection using the Web service. |
| Logon Attempts/Sec | Logons rate using the Web service that are being attempted. |
| Maximum Anonymous Users | Maximum number of users who established concurrent anonymous connections using the Web service. |
| Maximum Connections | The maximum number of simultaneous connections established with the Web service. |
| Maximum Non-Anonymous Users | The maximum number of users who established concurrent non-anonymous connections using the Web service from service startup. |
| Non-Anonymous Users/Sec | The rate of users that are making non-anonymous connections using the Web service. |
| Total Anonymous Users | The total number of users who established an anonymous connection with the Web service, counted from service startup. |
| Total Connection Attempts | The number of connections that have been attempted using the Web service, counted from service startup. |
| Total Logon Attempts | The number of logons that have been attempted using the Web service, counted from service startup. |
| Total Non-Anonymous Users | The total number of users who established a non-anonymous connection with the Web service, counted from service initialization. |
FTP Monitoring Counters
Bandwidth usage counters provide you with data related to the amount of traffic your server or FTP site is experiencing. Bandwidth usage counters can give you an excellent view of the bandwidth utilization over a period of time. The Bandwidth Usage Counters are listed in Table 16.5.
Table 16.5 Bandwidth Usage Counters
| Counter | Description |
| Current Blocked Async I/O Requests | Current number of requests that are temporarily blocked by the bandwidth throttle setting. Blocked requests are held in a buffer and then unblocked if more bandwidth becomes available, unless a timeout limit is reached. |
| Measured Async I/O Bandwidth Usage | The number of bytes received and sent by the FTP service, averaged over one minute. This is a measure of the total amount of FTP traffic supported by the FTP service. |
| Total Allowed Async I/O Requests | The number of user requests enabled by the FTP service since service startup. When you throttle bandwidth, the number of allowed user requests is restricted. |
| Total Blocked Async I/O Requests | The total number of requests that have been temporarily blocked by the bandwidth throttle setting since service startup. Blocked requests are held in a buffer and then unblocked if more bandwidth becomes available, unless a timeout limit is reached. |
| Total Rejected Async I/O Requests | The total number of user requests rejected (because of bandwidth settings) because service startup. When a request is rejected, it is not held in a buffer, unlike a blocked request. |
Throughput counters monitor the rate at which data is sent and received by your server or FTP site. Singular sites can be monitored or the entire server by selecting _total for object, Web service in Performance Monitor. See Table 16.6.
Table 16.6 Throughput Counters
| Counter | Description |
Bytes Received/Sec | The rate at which data bytes are received by the FTP service at the Application Layer; does not include protocol headers or control bytes. |
|
Bytes Sent/Sec | The rate at which data bytes are sent by the FTP service at the Application Layer; does not include protocol headers or control bytes. |
|
Bytes Total/Sec | The rate at which data bytes are sent and received by FTP service at the Application Layer; does not include protocol headers or control bytes. Bytes Total/sec is the sum of Bytes Sent/sec plus Bytes Received/sec. |
|
Total Files Received | The total number of files received by the FTP service since the service started. |
|
Total Files Sent | The total number of files sent by the FTP service since the service started. |
|
Total Files Transferred | The total number of files transferred by the FTP service since the service started. Files Total is the sum of Files Sent plus Files Received. |
User and connection counters monitor user and connection activity rates. These monitors are useful when trying to determine the number and types of connections established to your server or site. Singular sites can be monitored or the entire server by selecting _total for object, Web service in Performance Monitor. See Table 16.7.
Table 16.7 User and Connection Monitors
| Counter | Description |
|
Current Anonymous Users | The number of users who currently have an anonymous connection using the FTP service. If a client request for an anonymous connection is rejected and the client responds with valid authenticating data, the connection is counted as non-anonymous. |
|
Current Connections | The current number of connections established with the FTP service (sum of anonymous and non-anonymous users). The count is the current total for all FTP sites combined, regardless of what you choose for Instance. |
|
Current Non-Anonymous Users | The number of users who currently have a non-anonymous connection using the FTP service. If a client request for an anonymous connection is rejected and the client responds with valid authenticating data, the connection is counted as non-anonymous. |
|
Maximum Anonymous Users | The maximum number of users who established concurrent anonymous connections using the FTP service (since service startup). |
|
Maximum Connections | The largest number of simultaneous connections established with the FTP service since service startup. The count is the maximum for all FTP sites combined, regardless of what you choose for Instance |
|
Maximum Non-Anonymous Users | The maximum number of users who established concurrent non-anonymous connections using the FTP service (since service startup). If a client request for an anonymous connection is rejected and the client responds with valid authenticating data, the connection is counted as non-anonymous. |
|
Total Anonymous Users | The total number of users who established an anonymous connection with the FTP service (since service startup). If a client request for an anonymous connection is rejected and the client responds with valid authenticating data, the connection is counted as non-anonymous. |
|
Total Connection Attempts | The total number of connections to the FTP service that have been attempted since service startup. The count is the total for all FTP sites combined, regardless of what you choose for Instance. |
|
Total Logon Attempts | The total number of successful logons to the FTP service since the service started; does not include failed logon attempts. To calculate failed attempts (where clients were able to connect but not log on), subtract Logon Attempts from Connection Attempts. |
|
Total Non-Anonymous Users | The total number of users who established a non-anonymous connection with the FTP service (since service startup). If a client request for an anonymous connection is rejected and the client responds with valid authenticating data, the connection is counted as non-anonymous. |
Implementing Performance Modifications
Now you have the performance data that dictates that you must make a change to increase performance or at least return it to its previous state. Based on the data you have, you go ahead and plan some configuration changes. How will you know if they were successful? You guessed it. You monitor performance and log the changes. The key that makes great administrators great is the fact that they know their tools, use them, and plan accordingly.
Using Event Viewer to Uncover Errors
The Event Viewer is installed in Windows NT Server by default. The Event Viewer's sole purpose is to log changes made to the server's System, Security, and Application logs. These changes are logged as Error, Information, Success Audit, and Failure Audit. This tool can make a large difference in your troubleshooting of performance related issues. There are many Services, Security Audits, and Applications that log their errors as well as information data to the Event Viewer. System data commonly logs informational data or service failures. If your server suddenly cannot find a domain controller for your network, a good place to start is in the System log in the Event Viewer. Some applications that log data to the Event Viewer include SQL Server or the Internet Information Server. Data that is logged in the Application log is generally informational or to report application errors. Security Audit successes or failures are generally created by enabling auditing for specific user accounts directory and/or file permissions.
You can enable system wide auditing through the User Manager for Domains and selecting Audit from the Policies menu (see Figure 16.2). Additionally, you can specify directory and file auditing for particular accounts by selecting the file or directory and then choosing Properties from the File menu (see Figure 16.3). In the Properties dialog box, Security tab for the selected object, and you can enable file or directory auditing for an account. In the User Manager for Domains Audit Policy dialog box, you can selectively audit successes and failures for the events listed in Table 16.8.
Click Here For Figure
FIG. 16.2
Audit Policy Dialog Box.
Table 16.8 Events for Auditing Successes and Failures
|
Item Logged | Description |
|
Logon and Logoff | A user logged on or off, made a network connection. |
|
File and Object Access | User accessed a directory or file that had directory or file auditing enabled. |
|
Use of User Rights | User exercised his user rights, except for logon/logoff purposes. |
|
User and Group Management | User or group account was created, renamed, password changed, enabled, or disabled. |
|
Security Policy Changes | User rights, domain trusts, or audits policies changed. |
|
Restart, Shutdown, and System | User shutdown, restarted server, or a system security policy was changed. |
|
Process Tracking | Provide detailed tracking for program execution indirect object access and process exits. |
Click Here For Figure
FIG. 16.3
Directory Auditing Dialog Box.
The Event Viewer allows you to filter logged data by Date, Time, Source, Category, Event, User, and Computer. To filter by any of these categories, select Filter Events from the View menu. Additionally, you can view the details of a particular event by selecting it and either double-clicking or selecting Detail from the View menu.
The Event Log Settings can be changed for the size of the log for the Application, Security, or System logs. Additionally, you can change the method of Event Log Wrapping. The default setting is Overwrite Events Older than 7 days with the number of days configurable. The other two options are to Overwrite Events as Needed, which is particularly useful if you are low on disk space, or Do Not Overwrite Events (Clear Log Manually).
Using TCP/IP Troubleshooting Utilities
The Microsoft TCP/IP stack is a collection of protocols and tools for troubleshooting network connectivity[md]that network connection being your LAN, WAN, or the Internet. The Microsoft TCP/IP stack conforms to the Internet Engineering Task Force (IETF) standard. There are, however, some TCP/IP stacks that add customized functionality for proprietary reasons. You are better off sticking with a TCP/IP stack designed for or shipped with the operating system to avoid compatibility issues.
Troubleshooting Utilities
The Microsoft TCP/IP stack includes some basic command-line utilities that can help you troubleshoot connectivity problems with your network connection. Following is a list that describes each utility and their use:
ARP
Address Resolution Protocol (ARP) is responsible for creating a cache of IP's resolved to hardware address. The ARP utility allows you to display and modify the ARP table that contains IP to Hardware Address. The flags for ARP are as follows:
ARP -s inet_addr eth_addr [if_addr]
ARP -d inet_addr [if_addr]
ARP -a [inet_addr] [-N if_addr]
The flags for ARP are the following:
-a
Displays current ARP entries by interrogating the current protocol data. If inet_addr is specified, the IP and Physical addresses for only the specified computer are displayed. If more than one network interface uses ARP, entries for each ARP table are displayed.
-g
Same as -a. inet_addr specifies an Internet address.
-N if_addr
Displays the ARP entries for the network interface specified by if_addr.
-d
Deletes the host specified by inet_addr.
-s
Adds the host and associates the Internet address inet_addr with the Physical address eth_addr. The Physical address is given as six hexadecimal bytes separated by hyphens. The entry is permanent. eth_addr specifies a physical address. If if_addr is present, this specifies the Internet address of the interface whose address translation table should be modified. If not present, the first applicable interface is used.
Finger
Used to display user information for a remote system running the finger service. Output varies based on the remote system.
FINGER [-l] [user]@host [...]
-l Displays information in long list format.
user Specifies the user you want information about. Omit the user parameter to display information about all users on the specifed host.
@host Specifies the server on the remote system whose users you want information about.
Hostname
Shows the host name for your local machine.
Ipconfig
The Windows NT IP Configuration utility. The following is the syntax for Ipconfig:
ipconfig [/? | /all | /release [adapter] | /renew [adapter]]
The flags for Ipconfig include the following
/?
Displays this help message.
/all
Displays full configuration information.
/release
Releases the IP address for the specified adapter.
/renew
Renews the IP address for the specified adapter.
The default is to display only the IP address, subnet mask, and default gateway for each adapter bound to TCP/IP.
For Release and Renew, if no adapter name is specified, then the IP address leases for all adapters bound to TCP/IP will be released or renewed.
Netstat
Displays protocol statistics and current TCP/IP network connections. The syntax for Netstat is:
The following is the syntax for Netstat:
NETSTAT [-a] [-e] [-n] [-s] [-p proto] [-r] [interval]
The flags for Netstat include the following:
-a
Displays all connections and listening ports. (Server-side connections are normally not shown).
-e
Displays Ethernet statistics. This might be combined with the -s option.
-n
Displays addresses and port numbers in numerical form.
-p proto
Shows connections for the protocol specified by proto; proto might be tcp or udp. If used with the -s option to display per-protocol statistics, proto might be tcp, udp, or ip.
-r
Displays the contents of the routing table.
-s
Displays per-protocol statistics. By default, statistics are shown for TCP, UDP, and IP; the -p option can be used to specify a subset of the default.
Interval
Redisplays selected statistics, pausing interval seconds between each display. Press Ctrl+C to stop redisplaying statistics. If omitted, netstat will print the current configuration information once.
Nbtstat
Displays protocol statistics and current TCP/IP connections using NBT (NetBIOS over TCP/IP).
The syntax for Nbtstat is:
NBTSTAT [-a RemoteName] [-A IP address] [-c] [-n] [-r] [-R] [-s] [-S] [interval] ]
The following are the flags for nbtstat:
-a (adapter status)
Lists the remote machine's name table given its name.
-A (Adapter status)
Lists the remote machine's name table given its IP address.
-c (cache)
Lists the remote name cache including the IP addresses.
-n (names)
Lists local NetBIOS names.
-r (resolved)
Lists names resolved by broadcast and via WINS.
-R (Reload)
Purges and reloads the remote cache name table.
-S (Sessions)
Lists sessions table with the destination IP addresses.
-s (sessions)
Lists sessions table converting destination IP addresses to host names via the hosts file.
RemoteName
Remote host machine name.
IP address
Dotted decimal representation of the IP address.
Interval
Redisplays selected statistics, pausing interval seconds between each display. Press Ctrl+C to stop redisplaying statistics.
Ping
Packet Internet Groper. Used to test network connections.
The syntax for Ping is:
ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS] [-r count] [-s count]
[[-j host-list] | [-k host-list]] [-w timeout] destination-list
The following are the flags for ping:
-t
Pings the specified host until interrupted.
-a
Resolves addresses to host names.
-n count
Number of echo requests to send.
-l size
Sends buffer size.
-f
Sets Don't Fragment flag in packet.
-i TTL
Time To Live.
-v TOS
Type Of Service.
-r count
Records route for count hops.
-s count
Timestamp for count hops.
-j host-list
Loose source route along host-list.
-k host-list
Strict source route along host-list.
-w timeout
Timeout in milliseconds to wait for each reply.
Route
Manipulates network routing tables.
The following is the syntax for Route:
ROUTE [-f] [command [destination] [MASK netmask] [gateway] [METRIC metric]]
The following are the flags for route:
-f
Clears the routing tables of all gateway entries. If this is used in conjunction with one of the commands, the tables are cleared prior to running the command.
-p
When used with the ADD command, makes a route persistent across boots of the system. By default, routes are not preserved when the system is restarted. When used with the PRINT command, displays the list of registered persistent routes. Ignored for all other commands, which always affect the appropriate persistent routes.
Command
Specifies one of four commands.
PRINT
Prints a route.
ADD
Adds a route.
DELETE
Deletes a route.
CHANGE
Modifies an existing route destination. Specifies the host.
MASK
If the MASK keyword is present, the next parameter is interpreted as the netmask parameter.
Netmask
If provided, specifies a subnet mask value to be associated with this route entry. If not specified, it defaults to 255.255.255.255.
gateway
Specifies gateway.
METRIC
Specifies the metric/cost for the destination.
All symbolic names used for destination are looked up in the network database file NETWORKS. The symbolic names for gateway are looked up in the host name database file HOSTS.
If the command is PRINT or DELETE, wild cards can be used for the destination and gateway, or the gateway argument can be omitted.
Tracert
Allows you to trace the packet route to a specific host.
The following is the syntax for tracert:
tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_
The following are the flags for Tracert:
-d
Does not resolve addresses to hostnames.
-h maximum_hops
Maximum number of hops to search for target.
-j host-list
Loose source route along host-list.
-w timeout
Waits timeout milliseconds for each reply.
While there are no solid steps to troubleshooting network performance problems, the TCP/IP utilities should give you some insight when it comes to TCP/IP performance.
Configuring ODBC Loads
Microsoft Internet Information Server 4.0 (IIS) includes ActiveX Data Objects (ADO). ADO provides a small size, high-speed, low overhead method for connecting to a database through a provider such as ODBC or Microsoft OLE DB. It does not emphasize an object model hierarchy. This allows ADO to be smaller and faster. It does, however, leave you an open door to create and add objects to suit your needs. ADO contains the following features:
- Independently-created objects
- Batch updating
- Support for stored procedures with in/out parameters and return values
- Different cursor types, including the potential for support of back-end-specific cursors
- Advanced record set cache management
- Support for limits on number of returned rows and other query goals
- Support for multiple record sets returned from stored procedures or batch statements
- Free-threaded objects for efficient Web server applications
Because ODBC is still supported and used, we will cover some methods for tweaking performance from your ODBC connections. If you have upgraded from IIS 3.0, you will be able to take advantage of configuring your own ODBC connection pooling.
Connection pooling is a feature introduced in ODBC 3.0. Pooling allows ODBC applications to reuse connections from a pool of connections that have already been initiated. When a connection is made and placed in the pool, ODBC applications can use the same connection without having to establish a new connection.
ODBC pooling is only available in a Free Threaded model. This is because in connection pooling the connect/disconnect procedure needs to be handled by different threads. Rather than being handled through a connection pool where the connection are Apartment Threaded.
You can enable ODBC connection pooling in IIS 4.0 through the Internet Service Manager. Follow these steps:
- In the Internet Service Manager, select the directory where you want to enable connection pooling.
- From the File menu, select Properties, and then click the Home Directory or Directory tab.
- Click the Configuration button.
- Click the Other tab and select the Pool ODBC Connections check box.
- Type the timeout value for the connection in the Timeout text box. Click OK.
Because ADO supports multiple record sets returned from stored procedures or batch statements, you can increase performance on queries and calculations by allowing the back-end database server to do the work rather than the server from where you initiated the connection. There are ways to balance the load from the Internet server to the Database server. There are, however, some limitations to what we can do. For instance, there is no way for you to monitor connection pools with performance counters.
Understanding IIS Logging
A useful and pertinent tool to help you with your server-side loading is IIS logging. The logging that is done by IIS is not related to the logging that you expect to see in the Event Viewer. IIS logging is done in four different formats that range from ASCII- to ODBC-compliant databases like SQL Server. Logging provides you with the necessary information to plan your server load balancing, security, potential mapping problems, site visitation, and popularity.
The four types of logging that are available to IIS are:
- Microsoft IIS Log Format
- NCSA Common Log File Format
- W3C Extended Log File Format
- ODBC Logging
Microsoft IIS Log Format
The Microsoft IIS Log Format - Fixed ASCII format records more items of information than the NCSA Common format. The Microsoft IIS log format includes the following fields:
- User's IP address
- User name
- Date
- Time
- Service
- Computer Name
- IP Address of Server
- Elapsed time
- Bytes Received
- Bytes Sent
- Service Status Code
- Windows NT Status Code
- Name Of Operation
- Target Of Operation
The logged items are separated by commas, making the format easier to parse than the other ASCII formats, which are space separated. The time is recorded as local time or server time.
The following table shows the file formats for the Microsoft IIS log:
| By file size | inetsvnn.log |
| Daily | inyymmdd.log |
| Weekly | inyymmww.log |
| Monthly | inyymm.log |
NCSA Common Log File Format
The National Center for Supercomputing Applications (NCSA) common format is a fixed ASCII format, available for Web sites but not FTP sites. Basic information is recorded. The NCSA Common Log File Format includes the following fields:
- Remote hostname
- User name
- Date
- Time and Greenwich Mean Time(GMT) offset
- Request type
- Service status code
- Bytes sent
Logged items are separated by spaces; time is recorded as local time or server time.
The following table shows the file format for the NCSA Common Log File Format:
| By file size | ncsann.log |
| Daily | ncyymmdd.log |
| Weekly | ncyymmww.log |
| Monthly | ncyymm.log |
W3C Extended Log File Format
The W3C Extended Log File Format is a customizable ASCII format. You can configure the fields (items) you want to record. You are open to specifying the data you want collected without creating the overhead for items you don't want logged. Time is recorded as Greenwich Mean Time. The W3C Extended Log File Format allows for the customized logging of the following fields:
| Date | The date on which the activity occurred. |
| Time | The time the activity occurred. |
| Client IP | The IP address of the client. |
| User Name | The name of the user. |
| Service Name | The Internet service running on the client. |
| Server Name | Name of the server where log entry was generated. |
| Server IP | The IP address of the server on which the log entry was generated. |
| Method | The action the client was trying to perform (for example, a GET command). |
| URI Stem | The resource accessed[md]for example, an HTML page, a CGI program, or a script. |
| URI Query | The query, if any, the client was trying to perform[md]that is, one or more search strings for which the client was seeking a match. |
| Http Status | The status of the action, in HTTP terms. |
| Win32 Status | The status of the action, in terms used by Windows NT. |
| Bytes Sent | The number of bytes sent by the server. |
| Bytes Received | The number of bytes received by the server. |
| Time Taken | The length of time the action took. |
| User Agent | The browser used on the client. |
| Cookie | The content of the cookie sent or received, if any. |
| Referrer | The site on which the user clicked a link that brought the user to this site. |
The following table shows the file format for W3C Extended Logging File Format:
| By file size | extendnn.log |
| Daily | exyymmdd.log |
| Weekly | exyymmww.log |
| Monthly | exyymm.log |
ODBC Logging Fixed Format
ODBC Logging is a fixed format logged to a database. Items logged to the ODBC database are:
- User's IP address
- User name
- Request date and time
- HTTP status code
- Bytes received
- Bytes sent
Action (for example, a download carried out by a GET command)
Target (for example, the file that was downloaded).
The time is recorded as local time or server time. With this option, you must specify the database to be logged to and set up that database to receive the data.
Utilizing a database program that is ODBC-compliant (for example, Microsoft Access or Microsoft SQL Server) you must create a table with the following fields:
| Field Name | Field Type |
|---|
| ClientHost | varchar(255) |
| Username | varchar(255) |
| LogTimedatetimeService | varchar(255) |
| Machine | varchar(255) |
| ServerIP | varchar(50) |
| ProcessingTime | Int |
| BytesRecvd | Int |
| BytesSent | Int |
| ServiceStatus | Int |
| Win32Status | Int |
| Operation | varchar(255) |
| Target | varchar(255) |
| Parameters | varchar(255) |
IIS includes a SQL template file that can be run in a SQL database to create a table that will accept log entries from IIS. The file Logtemp.sql, is located by default in the \WinntRoot\system32\IISRoot directory.
To prepare your server to log to an ODBC database, you must configure a System Data Source Name (DSN). Just follow these steps:
- In the ODBC Control Panel, select the System DSN tab.
- Click the Add button and select the ODBC driver for your database.
- Type in the name of your new DSN in the Name text box.
- Type in a description in the description text box.
- Select the server or database source in the text box and click the Next button.
- In the following dialog box, select the Authentication type if you are using a SQL database.
- The New DSN Wizard then allows you to test your connection to your database.
From Here
Understanding and planning for server-side loading is not an exact science. There are, however, a number of tools that you can use to determine, balance, and optimize server loads. You have taken a look at using and setting up Performance Monitor to help you determine server loads through various counters. It is through the creation of baselines and scheduling of performance logs where you can maximize your understanding of the performance measures of your server(s).
The Event Viewer provides a wealth of information that can be referenced to determine the overall status of your server. It provides for the tracking of system, security, and application changes. These changes are logged as Error, Information, Success Audit, and Failure Audits.
TCP/IP provides some basic command-prompt utilities to test network functionality. These tools can help you understand where there are network connectivity problems and how to deal with them.
We have taken a look at how you can improve ODBC connectivity on a server. While you can improve performance through ODBC connection pooling, you are limited by the incapability to directly monitor the performance of those connection pools.
Finally, we looked at the IIS server logging methods available. It is through these logs where you can review the kind of traffic your server is experiencing and determine how to plan for security, site design, and load distribution.
The following chapters provide more information related to Server-Side Loading.
- Chapter 17, "Using the OSSA Suite of Server Management Tools," show some additional tools.
- Chapter 18, "Trouble Shooting Techniques for Your Server," details problem solving on your server.
- Appendix E, "Installing and Configuring Windows NT Server," discusses the issues in server configuration.
|
