When troubleshooting an issue on a Production environment
To isolate an issue to a specific page/request on a Production environment use the IIS Request Monitoring module. The Request Monitor needs to be enabled as a Windows Feature. it is located at Web Server (IIS) -> Web Server -> Health and Diagnostics -> Request Monitor.
With the feature enabled do the following:
1. In IIS click on the server (not a specific site)
2. Go to Worker Processes
3. Go to the specific worker process to be monitored
4. Click F5 (refresh) and monitor the Time Elapsed column
Most commonly the cause for performance problem are widgets placed on pages or page templates.
Execute the below test to narrow down the cause to a specific widget.
1. Create a duplicate for one page that when loaded is loading either slowly or the CPU spikes when it is requested.
2. On the duplicated page remove a widget and view the page, check if the problem still occurs. Make a note of what widget got removed.
3. If the problem persists after the removed widget, remove one more widget and make a note of the widget that got removed
4. Keep repeating those actions remove a widget and view the page until the problem is gone.
When the problem is gone the last removed widget is the one that is causing the issue. To confirm add it back to the page and confirm that the problem replicates.
In case all widgets are removed from the page, but the problem replicates execute the same action on the page template used for this page.
5. Duplicate the page template and assign the duplicated template to be the page template for the duplicated page
6. Perform steps 2 - 4 over the page template to narrow down the problematic widget.
When troubleshooting an issue on a non-Production environment
It is best to isolate the possible cause of the problem in order to have more information about what is causing the slowdown.
This can be determined by a test. For best results install TinyGet - it is a small program part in the IIS6 resource kit that is meant for performance testing. Refer to Link 1 in the notes for a download link.
The tool simulates traffic to the site. This way the CPU load and memory usage can be examined, similar to the load tests in Visual Studio.
Here are the steps to take.
1. Run the site on a computer where local IIS can be accessed and the applications and processes can be monitored using the Windows Task Manager
2. Choose one page which is loading slowly.
3. Duplicate the page. This will be the copy of the page for the test.
4. Run TinyGet ( See link 2 in the notes for a syntax tutorial) or use the sample below:
tinyget -srv:localhost -port:65132 -uri:/home -threads:60 -loop:100000 -h
-srv: name of the server
-port: the port number on which the site is tunning
-uri: this is the url of the page that was selected in step 3
-threads: the threads on the requests made to the page (it simulates 60 users browsing the page)
-loop: the users will be requesting the page for 10000 times
-h: this displays page header information, so lots of text will start moving when the Tinyget starts to load the page
(Note: TiniyGet might not start if threads or loop: values that are too big for the computer to handle, lower the values if it does not start).
5. Start the load (making requests to the page with TinyGet) on the page, which is chosen for the test and open the windows task manager. Monitor the CPU load for the IIS process.
6. Monitor how much CPU is consumed.
7. Information of how much CPU and memory this page is using when requested with TiniyGet is gathered.
8. Edit the page duplicated and remove all widgets from the page. Publish it and load this page with Tinyget (changing the URI to point to the duplicated page URL
9. Monitor the CPU usage of this empty page. The CPU must be drastically lower - around 2-3 percent.
10. Compare the duplicate page and the original page and start to add the widgets from the original page to the duplicated page - one by one. When new widget is added, run TinyGet again and check how much CPU is used.
11. At some point, the CPU usage will the same as on the original page. This should be caused by the last widget you have added before performing the test. Remove all widgets except this one and confirm the test. If this widget is custom widget review the code for possible infinite loops or calling .ToList() several times which creates lots of objects in memory and causing the performance hit on the page.
For more performance improvement tips refer to Link 3 and 4
in the notes