It could be that you just have a dodgy rendering that is running on every page and is then cached for that page; to see if this is the case you can profile Sitecore pages.
You can investigate this by clicking on the "Debug" option
and scrolling to the bottom of the page to see the speed of renderings:
From here you can either optimise the code, or check ...
Possible answers to 1,2,3...
Sounds like you need to do a bit of tuning on your caches. Sitecore has a number of "admin" pages which help you diagnose problems such as this - you can use the cache admin page to monitor the current size, configured size and vectors of the individual caches, include prefetch. To access this page, browse to http:///sitecore/...
By default Sitecore doesn't use the Roslyn compiler nuget packages Microsoft.Net.Compilers and Microsoft.CodeDom.Providers.DotNetCompilerPlatform packages, and instead will use the version of Roslyn installed on the system.
I've seen a very noticeably improved compilation performance improvement when using the latest versions of those packages.
From numerous experiments, I have put together the following tips and tricks.
Note that a good score under the desktop tab is considerably easier to achieve, the mobile score in our responsive sites is the real score we should benchmark against.
Backend Vs Front End
Page speed can be divided into two distinct parts. Backend server response and front ...
I think this URL speaks to your issue: https://kb.sitecore.net/articles/404548
Among the other suggestions there, try to reload the perf counters:
Start an administrator command prompt.
Run unlodctr .NETFramework.
Run lodctr %WINDIR%\Microsoft.NET\Framework\\CORPerfMonSymbols.ini
where is the directory of the .NET Framework version which contains the ...
To round up this topic, we ended up using the Razor Generator plugin of visual studio.
And added the assemblies to the precompilation section in sitecore config. (This is the same method sitecore uses to speed up experience editor.)
I just put a ticket in with Sitecore for this last week. Here is the fix from Sitecore. The fix allows you to pick how long the call will wait before it return a *+ result with no count.
The behavior you reported was registered as a bug in our bug tracking system.
Please use the link below to download the patch fixing your issue:
I agree with you, datasource count sometimes makes no sense.
But from what I know there is no config which you could use to hide this functionality.
You can remove this call by editing this file:
Find function renderDatasourceUsagesCommand and replace it with:
You're going to need a more than 10 servers to do 2M hits per second. Assuming each page is 100 hits, you need to serve 20k pages each second. Caching strategies will be critical. MongoDB is going to log gigs each day. IIS logs will be 10's of gigs each day. Disk speed will be critical. Akamai will be needed for all static assets. You need to limit ...
I can give some input regarding App Initialization in general on Azure App Service:
During slot swap, you don’t want your 'preprod' to be activated into production (swap) without having been warmed up beforehand. Using AppInit the swapping operation will only occur once the load balancer received an HTTP Response from the init module. (Note this response ...
As the comments on the question rightly point out; there could be a number of potential sources for this event that happened to you. As such, I don't know if a real answer could ever be found.
That said, I will attempt an answer. What you're getting here is just my experience summed up to the best guess I can come up with. I will also provide you means to ...
To add to this, there are some modules out there for archiving versions:
There are some good blog posts about options for archiving too:
https://community.sitecore.net/technical_blogs/b/sitecorejohn_blog/posts/rules-engine-actions-to-remove-old-versions-in-the-sitecore-asp-net-cms - a nice ...
There is a very good article on https://community.sitecore.net/developers/f/8/t/531 which deals with the same issue. I actually followed it up last year and it solved the issue that you are having as well.
You can usually improve this by tuning the settings for our queues.
A good post in this can be found here: https://briancaos.wordpress.com/2016/08/12/sitecore-event-queue-how-to-clean-it-and-why/
What I normally do:
On the CM: clean the eventqueue very aggressively
On the CD:
poll the eventqueue less aggressively
disable the eventqueue cleaning
You could use a patch file to do this too. Using the <patch:delete /> method:
<hook type="Sitecore.Diagnostics.MemoryMonitorHook, Sitecore.Kernel">
Add that to a config in your include folder and it will remove the memory hook config without having to directly edit the web.config file.
We managed to identify the root cause of our memory leak. With help of MS and Sitecore, memory dump had lots of our controller and services hanging off of Root scope.
By design the sitecore disposes the objects on request end. Given that the controllers injected by Autofac were not compatible with Sitecore controllers, the objects didn't get disposed. As a ...
I have consulted with Sitecore support on this. Regarding resources, all of them are important: Memory, CPU, Disk Latency and Database DTU's.
I have also checked my cache settings and noticed there where 2 caches beyond there limits:
SqlDataProvider - Prefetch data (core) with 6383 items and a size of 43.3 MB and maxsize of 50MB
SqlDataProvider - Prefetch ...
This ended up being a DNS issue; the site name was not being resolved properly. I took @maz's advice and called [System.Net.Dns]::GetHostEntry("siteHostName") in PowerShell (I didn't have Sitecore PowerShell Extensions installed, so I just called it from PowerShell on the server). It took about 4-5 seconds and then the call would error out, and that was ...
Okay - so we've got to the bottom of this and it looks like it was just a misconfiguration issue when using SOLR cloud.
I'm posting this here for reference:
Rebuilding the index for SOLR cloud is detailed here
With the most important things being:
On the CM box the following should be setup:
<index id="sitecore_web_index" type=
You could write a publish:end:remote event that kicks off some logic to find all item versions "eligible for archiving," based on your criteria. You can then archive those versions that are n versions behind the latest.
Now that your auto-archiving logic is created, you need to actually perform the archiving. How you do ...
Session locking only affects requests from a single source. It's more evident in load testing than it is in real world situations, since most of the traffic is coming from a single source, or relatively small number of sources. We have seen performance improvements in code using the ReadOnly attributes for controllers in a load test scenario, but these don'...
Much faster way is to get descendants from index.
Query would be get all items that Path starts (contains) the same as current item + ID of item is different to current one.
Something like this:
var query = context.GetQueryable()
.Where(item => item["_path"].Contains(contentRootId))
.Where(item => !item.ID.Equals(contentRootId));
Solr can ...
I was suffering from a similar issue for the SQL server for different databases. Below are the details.
Cloud Environment: Sitecore Managed Cloud XP-Small and XP-Medium
Sitecore Version: Sitecore 9.1 Update 1
Cause of the issue: By default from Sitecore Managed Cloud Team indexing strategy was set to "onPublishEndAsyncSingleInstance" in CD role. And ...
Microsoft is going to retire Azure In-Role Cache on 30-Nov-2016, which Sitecore Azure module uses as a storage for session data. It's recommended upgrading the module to the latest version of 8.0 rev. 161110 or 8.1 rev.161109 and start utilizing the Azure Redis Cache with Sitecore Redis Session State provider.
For more details, see the following article:
My reply does not answer your question directly, because Azure caching is to be defined dynamically according to your load factor.
Nevertheless, for the high load website I would personally recommend the following:
Tune your Sitecore rendering output caches as per Sitecore official performance tuning guide (your case is section 4.4, but it always good to ...
Richard's answer is absolutely correct.
It removes the memory monitor hook completely.
If you want to disable it only, you can change the Check Interval attribute only with 00:00:00 value.
Just drop the patch config file to App_config\Include with the following content:
As a note, user persistence is optional with Federated Authentication.
Federated Authentication supports both virtual users and a membership-backed user. It is also possible to roll your own persistence if required.
Since the underlying Membership storage structure is unchanged, the same scaling limits apply as with previous versions.
NOTE: The official ...
No one is going to like this answer, but Sitecore resolved it by disabling FXM site manager. In the file
App_Config\Sitecore\FederatedExperienceManager\Sitecore.FXM.config they removed the section below. It would seem that the FXM site manager was loading slowly and when the normal site manager would fire up it would dead lock on FXM. Randomly it would not ...
However it is not recommended to keep your css and js files in sitecore media library but as you have already decided then you could use SquishIt libraries to bundle and minimize your css and js:
Link : https://www.nuget.org/packages/SquishIt
Sample code you need to write in your view file: