Using distributed cache delivers up to 200 times better startup and warmup performance for a “cold start”, when pages have not yet been compiled, and up to 5 times better startup and warmup when a node is restarted (pages have already been compiled). This results in improved scalability and high-availability, as well as better browsing experience for users who hit a newly started node. In-memory output cache storage certainly excels at providing the best average page response times once the site is warmed up. Distributed output cache still delivers very good average page response times, and this performance can be affected positively (or negatively) based on the distributed cache storage used.
Following is a detailed analysis of the performance improvements comparing in-memory and distributed output cache storages.
Testing the Sitefinity CMS performance with distributed cache storage is executed with the following setup:
Sitefinity running on 3 web server nodes in load balanced configuration hosted on AWS.
c5.xlarge - 4CPU, 8GB RAM
Web Server node 1
Web Server node 2
Web Server node 3
Redis cache configuration
Amazon ElastiCache for Redis cache used for NLB messaging and distributed cache storage.
1 node, cache.t2.medium.
Both Redis node and Sitefinity Web server nodes configured in the same AWS Region.
NOTE: When using distributed cache, the performance of your Sitefinity CMS site depends directly on the network latency and distributed cache storage type. For example, running the tests described in this article with ElastiCache for Redis node of type of cache.t2.medium results in 2 times better performance compared to using cache.t2.small. The cache.t2.small and cache.t2.medium are among the most affordable Redis cache storage types and are categorized as Low to Moderate network performance. Using higher-rated distributed cache storage might result in even better performance.
Sitefinity CMS configuration
Sitefinity CMS Multisite license
Website domain set to the load balancer URL Note: this configuration is required for the warmup module normal operation if distributed cache is used
250 MVC pages
Content block widget on each page
Page size (in KB)
Warm-up module configuration
Output cache settings:
Cache duration (in seconds)
The test results list the Sitefinity CMS performance in startup, warmup, and load test to reflect the full scenario of a newly started/restarted site spinning up and warming up, as well as website browsing under load by site visitors.
Test scenario description
In-memory output cache
Distributed output cache
Start any node for the first time (pages have not been compiled yet)
Compilation and warmup duration
Restart any node
(pages have already been compiled and exist in the ASP.NET Temporary fields)
Scale by adding a new node
The load test is executed against the same Siteifnity CMS website. The same Sitefinity CMS configuration and hosting configuration described in this article apply. The load test has been executed using Visual Studio load test agent running on a dedicated machine.
Load test configuration
Constant pattern (user browse the website all the time)
The load test is executed against a fully warmed up website (all nodes warmed up and initialized the output cache) to measure the differences in website performance when reading from In-memory vs Distributed cache.
Average response time
Back To Top
To submit feedback, please update your cookie settings and allow the usage of Functional cookies.
Your feedback about this content is important
Copyright © 2020 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, Ipswitch, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.
Powered by Progress Sitefinity