NOTE: Performance fine-tuning and debugging performance issues fall outside of the scope for support: https://www.progress.com/support/sitefinity-scope-of-support .
Measure, measure, measure
When dealing with performance issues, it is useful to know as precisely as possible what type of performance degradation we are talking about, e.g.
- An example of a page that takes a long time to load
- How long does it take to load?
- Is the page always slow to load regardless of the time of day?
- Is the page always slow do load on production and in development?
This allows a comparison between other environments and measures any improvement. For instance, if the same page loads normally off hours but is too slow during peak time, this is an indication the site is overloaded. On the other hand, if the same page takes a long time to load both on the production and development environment, a heavy load can be ruled out.
Where does the issue come from?
Loading the page using the developer console Network tab (press F12 on most browsers) provides the first clues about where the issue could come from. In particular, focus on the time it takes to load the main HTML page:
In the above example, the Web browser waits for 250ms for the main page to be ready to load ("Waiting (Time to First Byte)" metric), and 32ms to load it ("Content Download" metric).
- A long "Time to First Byte" is often an indication that the Web site takes a long time to generate the page.
- A long time to load is symptomatic of a slow network. Check with hosting provider.
General performance optimization
If Sitefinity takes too long to generate pages, check the following articles for performance optimization:
One can check if the Data Caching is enabled: under Administration > Settings > Advanced > Data, Enable data caching should be empty, so it gets the default value (True).
See Sitefinity documentation, cache settings https://www.progress.com/documentation/sitefinity-cms/administration-cache-settings for further information about Sitefinity Caching
Use Load Balancing
Websites which have to handle a large number of requests should be hosted in a load balanced environment with at least 2 instances. This will guarantee not only very high availability for the website, but also allow to execute procedures on the website without affecting its availability. One can, for instance, remove one of the instances from the load balancing, perform some maintenance operation and put it back online, while the other node handles all the requests during the maintenance.
This setup will also allow to warm-up the instance before letting it handle requests, and hide the waiting for that initial load.
Deployment of a new version of the website should always detach the instances from the load balancer one by one, perform the upgrade, warm them up and even then put them back on. In this way the website will provide a nice, consistent experience for the end users.
Static resources take some time to load: consider using a CDN
Faster system restart
Please refer to the Sitefinity startup performance
Speedup the Local development
Use SSD disk or RAM disk when possible. More information
Remove the unnecessary assembly references, keep only the ones needed and used, e.g. in case of using nuget packages
Install Roslyn compilation: https://www.nuget.org/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Usage of the Diagnostics module
If Diagnostics module is active, deactivate it by navigating to Administration > Modules & Services > Action (of Diagnostics module) > DeactivateBootstrapping
Host the site with IIS web server. Running the sites through local development servers (IIS Express) doesn`t count as a benchmark for speed because the web server is for development purposes and doesn`t have the full IIS Performance boosters.
Make sure the websites are not running debug mode. In web.config check the debug is set to false
For sites running Sitefinity version 10.1.6500 there is startup performance boosters. One of them is Sitefinity 10.1 itself and the other is the option to use Roslyn compiler (~ 6 times faster page compilation).
Details here: https://www.progress.com/blogs/sitefinity-cuts-web-site-startup-time-in-half
Another part of the bootstrap process is the code added in Global.asax on Application_Start
event and Boostrapper_Initialized
events. If there is a slow executing code or code that works through a large collection of data this will impact the startup.
If the site warmup module is configured based on this Sitefinity Documentation, site warmup https://www.progress.com/documentation/sitefinity-cms/site-warmup
it will slow down the site startup in order to preload certain pages. Check if it is configured and how many pages it preloads.Slow load for pages or a certain page
Slow compilation time. If the page has a lot of widgets that query data, this load of data from the page and from its page template needs to be executed once so that the page compiles and outputs HTML, this is the slowest process of the page request. Once compiled all will be faster. The compilation can be speeded up via installing Roslyn compiler.
In case the Roslyn compiler doesn`t improve the time to the first byte for the request to homepage then the page itself needs to be examined for causes of the problem.
Run a copy of the site locally out of the production server.
- measure the startup time
- remove a widget from the homepage and measure the time again.
- Keep removing widget until the load speed improves, the last removed widget is the one causing slowdowns.
- If all widgets from the page are removed, but it still loads slowly go to the page template and continue the removal process to narrow down a problematic component.
- move to the page template on which the page is based to narrow down the root or the problem to a widget on the page template.