a. Q: What can you derive from a ratio between 200 and 304 status codes? A: A 200 means that the server provided the file to the client and it was a successful request. A 304 means the file was retrieved from the client cache and no file was sent from the server. This improves the performance of the application and reduces the load on the server. The higher number of 304s is a good thing in relation to the 200s because it means there is less reliance on the server.
b. Use NET HELPMSG #, to find out what the sc-win32-status number means.
c. Q: Which sc-status codes do you want to analyze further? A: The 500s would be of particular interest because that means there was some kind of error responding to that request. The 64 sc-win32-status usually means that the IIS server can no longer determine where to send the response to, This happens often when requests take a while to respond and the user closes or refreshes the browser.
a. Q: Are those MAX values too big? A: The MAX time-taken looks long, 65 seconds, also the MAX cs-bytes and MAX sc-bytes look large as well. Looking at each of those requests to see if it is expected would be a valid approach and worth the effort.
a. Q: Any relation between request/response size and time-taken? A: In this example, the size of the file is pretty small, so it does not look like the slowness was caused by the file size.
b. Q: What can you conclude when comparing the relationship between request/response size and time-taken? A: If the time-taken is large and the size of the file is large, the reason for the slowness is likely due to the file size. If the file size is small then the issue may be caused by a network issue or a resource constraint, like 100% CPU consumption on the server.
a. Q: What file size is too big? A: The larger the file, if it is not cached on the client, the longer it takes to download. So the smaller the better and do your best to cache them on the client. Q: Should you reduce the sc-bytes value? A: In this case the file size is ok.
a. Q: Why would a client side file be big? A: Perhaps the client is uploading a file to the server or the client is posting contents of
a form to the server. Q: What is too big? A: there is really no hard rule on what is too big, if a file needs to the uploaded that is large you should consider streaming it using an asynchronous process.
a. Q: What causes 500’s… See Lab 25. A: These errors are typically caused by server side code. Look at the sub-status code for more tips.
b. Q: What actions can you take in IIS to prevent or troubleshoot them? A: exceptions do happen, but through logging and analysis of those logs you can pinpoint where the error is coming from and repair it. With logging, you would never find it.
Q: What is your overall conclusion and course of action? A: Overall the site is healthy excluding a few large XML files, a form that allows for the posting of a large amount of data and a few 500s.
Execute HTTP query —————–1————— to see all the errors reported at the HTTP.sys level, what does it tell you?
a. Don’t forget to change the Input Log Format…
b. Q: What do each of these s-reason values mean? A: Descriptions are discussed here.
c. Q: What conclusions can you make, how should/can you analyze further? A: after reviewing what these s-reason codes mean, I’d looked at the ones which mean the most to me. Also, the one which is occurring the most seems like a good place to start.
a. Search using date/time… perhaps this activity happened one a specific day from a specific IP address…
What are your conclusions?
Execute Event query —————–1————— to get a view of all the System events that happened on the server, what does it tell you?
a. Q: Which Event Types are important? A: EventTypes = 1 are errors and I would look at those in more detail using a query that gets the detail of the specific log.
b. Open the Event File in Event Viewer and view the details of events.
c. Q: How do you troubleshoot them further? A: Search online for the EventId or if there is a stack in the details of the event you can look if there are any known issues and perhaps there is a hotfix for it.
a. Same as previous…