When encountering IIS performance problems, you should start with log analysis. 1. Check the time-taken field to identify slow requests; 2. 10% of the time-consuming requests to locate specific pages or files; 3. Statistics the number of requests per minute to analyze concurrency; 4. Combining the sc-status field to view error trends; 5. Cross-verify the log with external indicators such as system resources and databases. By connecting time, path, status code and IP information, you can find out the bottleneck more efficiently.

When encountering IIS performance problems, many people think of the first thing they want is to look at the usage of server resources, but in fact, the log often hides more direct clues. If you want to quickly locate the bottleneck, you have to find the answers in the log.

View the response time distribution

The time-taken field in the IIS log is the key, which records the time (in milliseconds) taken for each request to process. If this value is generally high, it means that there is a problem with the processing efficiency. You can first use Log Parser or PowerShell to filter out the longest requests in the first 10% to see if there are any specific pages, APIs or static files to slow down the overall performance.

Common phenomena:

• time-taken of some dynamic pages lasts for more than 2 seconds
• Large file downloads cause frequent disconnection and retry of the client, increasing the average response time
• The same URL performs greatly in different time periods

Suggested practices:

• Use tools to batch analyze logs and find out the "slow request" pattern
• Pay attention to whether there are a large number of 4xx or 5xx errors with high response time
• Comparison of data changes between normal and abnormal periods

Analyze concurrency and request frequency

In addition to the time-consuming of a single request, it also depends on the concurrency. The number of requests per minute can be counted through date and time fields in the log. If a lot of requests suddenly increase during a period of time and the server response is slow, it may be a traffic spike or a DDoS attack.

You can aggregate data according to the time window to observe whether there are a large number of requests influx in a short period of time. Combining cs-username or c-ip fields, you can also see whether a user or IP is accessing at high frequency.

Note:

• If the number of requests per second is much higher than usual, but the CPU/memory is not full, it may be blocking the application layer.
• If the number of concurrency is not high but the response is slow, the problem may be in the database or third-party services.

Pay attention to status codes and error trends

The sc-status field in the IIS log records the response status code. Under normal circumstances, most of them are 200, but if a large number of 500, 503 or 404 suddenly appears, it is worth in-depth investigation.

For example:

• Multiple 500 errors have occurred in succession, which may be that there is an exception in the code logic that is not caught
• Frequent 404 requests may come from crawler scanning or configuration errors
• 503 There are many errors, usually related to the busy or crashed application pool

It is recommended to check the error type distribution regularly and combine the time point when the error occurs to determine whether it is related to deployment and configuration changes.

Cross-verification in combination with other indicators

Although logs can provide a lot of information, it is not enough. You can compare the request time and IP information in the log with Windows performance counters (such as CPU, memory, number of threads), SQL Server execution time, network delay, etc. to find the correlation.

for example:

• The log shows that a certain interface has slowed down, which just corresponds to the surge in SQL Server CPU.
• While an IP initiates a large number of requests, the number of queues for IIS thread pool increases

At this time, you can determine whether it is an external call problem or an internal resource bottleneck.

Troubleshooting IIS performance issues, don't just focus on monitoring charts, the details in the log are often more valuable. The key is to string together information such as time, request path, status code, and client IP to locate the real reason faster. Basically, these methods are just flexibly combined in practice.

The above is the detailed content of How to troubleshoot IIS performance issues using logs?. For more information, please follow other related articles on the PHP Chinese website!