...
How frequently does the indexing job run? When is is it scheduled and how long does it take? Does the site use real time indexing or full indexing?
...
XperienCentral Monitoring Tools
The Monitoring Dashboard allows you to Administrative Pages help you inspect many important metrics regarding your XperienCentral deployment. See also the Administrative Pages.
Log Files
Check the Tomcat log file for errors or warnings that appear often and also check the size of the log file. You can edit the logging.properties to customize the log entries (by severity). See Avoiding Clogged Logfiles. Is the logfile regularly rotated? Check the web server access log files to see the incoming HTTP requests. Pay special attention to the identity of the user-agents. Oftentimes bots like Googlebot and Bingbot generate high amounts of traffic during their crawls. Usually you can use tools of the bot owner to configure them for crawling your site.
...
There are job schedules that you configure in the General tab of the Setup Tool that can have a major impact on performance:
| Setting | Explanation |
|---|---|
formsengine_prehandling_cachetimeout | The PreHandlingElementHolderCacheRecalculator task evaluates whether a form element requires prehandling. If so, it updates the prehandling cache. By default, this is configured to run every 2 minutes. If your site has many form elements this could have a major impact on performance. In that case it might be a good idea to set this setting to a longer time period. |
current_rollover_detector_schedule | The CurrentRolloverDetectorImpl task checks whether content items need to be rolled over by looping over all content items every 5 minutes. A loop time of every 15 or 30 minutes may be better. |
contentindex_queue_poller_schedule | The IndexQueueServiceImpl task indexes the content index for inline search. Usually this is scheduled for every 20 seconds, however the indexing might take longer than that which causes a lock contention. |
contentindex_queue_iteration_limit | This setting which determines the maximum number of items to index when a full content index is triggered. |
contentindex_optimize_schedule | The content search optimizer runs a Lucene optimization exery x minutes. Optimizing is very expensive and causes a lot of input/output. In a lot of deployments it is a good idea to let this run once nightly. |
Clean up after Copying a Database
When you copy a database from one environment to another, you should clean some tables of cluster IDs that are not applicable in the new environment. This applies in particular to modules that use revision numbers per cluster node. If the cluster nodes are not removed, the main revision table cannot delete any records since it thinks that some cluster nodes are not yet up to date.
...
Check JIRA to find any known performance issues in a specific WebManager versionXperienCentral. Some known issues;
- Performance issue with file distribution on MS SQL 2012 (GXWM-29415)
- Personalization dialog very slow when BlueConic integration is active (GXWM-29507)
- Performance issue in page tree (same Ajax request fired 6 times) (GXWM-29107)
- Performance issue when many pages in page tree are expanded (GXWM-29112)
- Content index queue service runs fullIndex, even when limit is set to 0 (GXWM-29098)
- Major lock contention in IndexQueueServiceImpl (GXWM-29088)
- The Entity manager should use hasNode instead of catching PathNotFoundException for performance reasons (GXWM-29095)
Maximum Stale Time
There is a hidden feature setting called 'cache_max_stale_time' in web/setup on the General tab of the Setup Tool. By default, this value is 0 and so this feature is disabled. If the max stale time is bigger then 0, content is still returned from the cache for a while after the tiemstamp has expired. For example, if the max state time is 5 minutes, content for which a cached version is available is returned from the cache for another 5 minutes after the timestamp has expired. So this effectively creates a soft timestamp mechanism for all content.
...