Feedback
 
Did this article resolve your question/issue?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025

 


Article

Performance: How to isolate the cause of a performance problem in Sitefinity

« Go Back

Information

 
Article Number000071754
EnvironmentProduct: Sitefinity
Version: 4.x, 5.x, 6.x, 7.x, 8.x, 9.x, 10.x, 11.x, 12.x
OS: All supported OS versions
Database: All supported Microsoft SQL Server versions
Question/Problem Description

The site takes too much time to load during development. This is problematic when the site goes to the production server.

Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement Number
Cause
The site takes too much time to load.
Resolution

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 -uri:/home_duplicate ).
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
Workaround
Notes
References to Other Documentation: 
- Microsoft Download Center, Internet Information Services (IIS) 6.0 Resource Kit Tools: http://www.microsoft.com/download/details.aspx?id=17275
- Google code Archive, TinyGet: https://code.google.com/archive/p/toolsdotnet/wikis/TinyGet.wiki 
- Sitefinity Documentation, Optimize performance: https://www.progress.com/documentation/sitefinity-cms/best-practices-optimize-performance
- Sitefinity Blog, Development practices for performance optimization: http://www.sitefinity.com/blogs/slavoingilizov/posts/slavo-ingilizovs-blog/2012/03/14/5_practices_to_avoid_when_doing_sitefinity_development
Attachment 
Last Modified Date12/4/2019 9:29 AM