17

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 ...


13

The communication between the Content Delivery and Content Management box is handled through the Event Queue. Your Content Management instance triggers an event (i.e.: "publish:end:remote") This event is added to the EventQueue table in the database that is targeted by the event. for the "publish:end:remote" event is usually the "web" database unless you've ...


12

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/...


11

You've got a few options: The Simple Option: Add a width (see here: Sitecore Image Parameters) - the image sizes will be processed. The disadvantage of this approach is that you get a processing hit the first time the image is resized (it then caches the result I believe). A more complex option: You can build something which farms the images out to a CDN ...


10

The entirety of the CMS Performance Tuning guide that you linked is relevant for Sitecore 8.X. The guidelines and features discussed have not changed. The underlying architecture for some of the elements have changed (such as Caching) but how you tune has not. What's not in here are the additional performance improvements that can be done as a result of the ...


10

You could also use this... https://github.com/kamsar/Dianoga An automatic image optimizer for the Sitecore media library.


10

When publish:end:remote event is raised, there is an entry created in the core database EventQueue table. All the servers (including CD servers) check that table and executes all the handlers. In terms of performance impact, it all depends on the code which generates the files.


10

Habitat is an example implementation of the Helix guidelines and shouldn't be used as a starter kit. With that said, you should review what you will need now and remove what you can. It can always be brought back in at a later time if it's deemed appropriate.


10

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 ...


9

The sitecore_analytics_index stores information about interactions, contacts, and some other xDB entities. The more data you collect, the bigger the index will grow. The more visits you have in a given time period, the more frequent index reads and writes will be. Whether or not you should switch from Lucene to Solr depends on whether the high hard disk ...


9

If your throughput consist out of more than 100.000 writes per second, I would recommend you use an SSD. I think you should not overkill your machine. MongoDB cache will only take up to 10% of your available RAM to cache it's write actions. When you use the write concern w:majority on a replicaset your data will always be present in at least 2 (if you have a ...


8

In general, if your data nodes are hosted in different geographical regions, latency between them will be considered high. Write concern High latency will make the replication process slower, which means that using the write concern of w:1 is highly recommended in order to prevent performance degradation. On the other hand, if the majority of your nodes ...


8

One approach that we have used is to index the content of all data sources in a single computed field. You can search that field when searching the index. This can probably be improved, but it's a start. I believe this is also the approach the are using in the Habitat project. Copied/inspired from: http://kamsar.net/index.php/2014/05/indexing-subcontent/ ...


8

Sitecore comes with out of the box possibilities to configure media caching. Have a look at the Sitecore.config: <!-- MEDIA RESPONSE - CACHEABILITY The <see cref="HttpCacheability">cacheability</see> to use in media response headers. Possible values: NoCache, Private, Public, Server, ServerAndNoCache, ServerAndPrivate ...


8

Do we need to include both master and web db settings in CMS? Or just master settings in CMS. Only the master db will suffice. Web db items are only used when the site is accessed through the front-end which is usually not the case on CMS. Do we need to include master and web db settings in CD? Or just Web settings in CD. Only the web db. The master db is ...


8

Here's my understanding (from notes taken during a Mongo engagement a while back): for MongoDB, the more RAM the better. MongoDB performs everything in memory (by default) and flushes it to disk in a separate thread. An SSD drive will speed up the flushing process. Note, unless you force MongoDB to acknowledge writes only after you physically write to a ...


7

If you use Sitecore PowerShell Extensions you can make this process faster by wrapping it in an EventDisabler SPE has a Remove-ItemVersion cmdlet that lets you select the language(s) versions and also the max number of recent versions to keep. This means you don't need to archive and restore the needed versions. This code assumes v4+ of SPE: New-...


7

As a best practice, there should not more than 100 items under any node in Sitecore, Since Media in Sitecore are also store as Items so it is applicable for Media library as well. If you have more than 3000 media items under a single node then definitely it should restructure. Now come to the point of bucketing, creating bucket is an option in your case ...


6

Can't provide you with a list of recommendations for all agents, but as you mentioned the event queue I can give some information on the CleanupEventQueue task. As we had issues with ever growing event queue tables (as many others probably) we reached out to Sitecore support and together we came up with some patches to the configuration. The idea is: On ...


6

Most of the calls you mentioned are related to Sitecore Standard Fields. E.g. if you Content Editor is about to display Tracking field in a user friendly way, it does extra call to TrackingFieldDetails.aspx. What you can do is to uncheck Standard Fields in the VIEW tab of the ribbon (or use CTRL + SHIFT + ALT + T keyboard shortcut). That will hide the ...


5

To add to this, there are some modules out there for archiving versions: https://marketplace.sitecore.net/en/Modules/Version_Manager.aspx 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 ...


5

I would always make sure that your renderings output images with a max-width that is suitable for that rendering, so that any images larger than this uploaded by your editors isn't rendered onto the page at a size much larger than it needs to be. The beauty of the Sitecore media pipeline is that this processing is done on the fly and the images are cached ...


5

I think your Lucene index needs a trim. Especially if it hasn't been this slow always, but just gradually started degrading little by little. Since it's not a production server, my first recommendation would be to issue a full Index Rebuild and let it run for however long it needs. If you see a really slow rebuild speed, your problem lies elsewhere ...


5

The general reasons for using Solr instead of Lucene are: When you need to index large numbers of items (50,000 and up), Solr performs better, so in your case you have to use SOLR Solr is more robust. If your site depends on search as the primary interface, consider using Solr. If you use multiple content delivery servers (or plan to do so later), use ...


5

Sitecore populate prefetch catches just at application inititialization, and it maintains it during the lifetime of the application. Is not possible to update after you run the app and the prefetch cache is already initialized. Bellow are some information about prefetch cache : There is a prefetch cache for each database Each cache entry is populated from ...


5

Without having done any testing, I think that one of the important considerations here would be "what kind of personalization conditions will cause performance impacts?" The rules engine is very performant in general, so it's really the performance of the individual conditions that would matter. Some personalization conditions would be relatively ...


5

You can try the following to identify your issues: Enable Sitecore Pipeline Profiling by setting <setting name="Pipelines.Profiling.Enabled" set:value="true" /> <setting name="Pipelines.Profiling.MeasureCpuTime" set:value="false" /> and browsing to /sitecore/admin/pipelines.aspx Profile a Sitecore Page by going into debug mode (add these ...


5

The class of interest here is Sitecore.Diagnostics.PerformanceCounters.DataCount (in Sitecore.Kernel.dll). You can simply use the following technique: var initialItemsAccessed = Sitecore.Diagnostics.PerformanceCounters.DataCount.DataItemsAccessed.Value; SomeMethod();//the method you want to assess var totalItemsAccessed = Sitecore.Diagnostics....


4

To answer your questions: Every latency you have, is always too much latency. You would always prefer to not have too much latency. What I would do is set up the replicaset and check which one causes the most latency and the set up that specific note to never becoming the primary. It can still vote but will never have the upper hand in become a primary, ...


4

The Analytics index can cripple Solr too, I've seen this in production environments. You want to pay special attention to the memory settings for Solr and the JVM and make sure you have enough disk capacity and RAM to handle it as it grows. As merges take place, the analytics index of ~1 million documents can grow up to 20 GB in size. It may not be enough ...


Only top voted, non community-wiki answers of a minimum length are eligible