Troubleshooting Salesforce B2C Commerce Performance

Use the object management technical report, pipeline profiler, and other analytic tools to monitor new code after deployment to identify or prevent performance problems. When you have experiences a performance issue, there are several steps you can take to identify the cause yourself and quickly resolve the issue, without needing to contact your support provider.

Monitoring Performance of New Code and Data

When you push a new version of your storefront code or receive a general availability (GA) release from B2C Commerce, you can monitor the performance of B2C Commerce to see if the new code caused changes to the performance of B2C Commerce. You can use the Pipeline Profiler and the Object Churn Trends report to monitor B2C Commerce. You should also monitor job performance and search indexing and optimize it if possible.

Pipeline Profiler

Use the Pipeline Profiler to monitor performance of critical pipelines. Grid wide median responses for three of the most critical pipelines are:
  • Search-Show = 400 ms
  • Product-Show = 320 ms
  • Home-Show <= 100 ms
See Using Pipeline Profiler.

Object Churn Trends Report

Monitor database object churn trends to see if the new code has change the profile of your database transactions or presents any concerning trends. In general, new spikes of database transactions in the report might require examination, even if no performance issues are immediately present. See also Examining Database Performance.

Salesforce suggests examining the 24 hours before and after a code release to compare performance, assuming that the two 24 hour periods have comparable traffic. If the previous 24 hours has much heavier or lighter traffic, you might want to compare the current performance to another 24 hour period with a similar traffic load.

In particular, we recommend examining the Basket and Session objects together, as these have a history of causing performance issues when misused. In particular, you can expect to see a lower graph of Basket objects compared to Session objects. When Basket and Session objects are identical, it usually indicates that a basket is being created automatically for each session, instead of when a customer adds an item to the basket. This is unnecessary and known to cause performance issues.
Tip: Because the report aggregates the transactions of all storefronts on the Production instance, if your storefronts have different code for sessions and baskets, a fix might not be required for all storefronts.

Monitor Job Runtimes

Monitor job runtimes on a regular basis. Jobs running over 1 hr should be analyzed for possible optimizations.

Make sure that your data import uses best practices:
  • Don't include static data (resources) in daily scheduled backups. A site can be exported without static content.
  • Run impex jobs sparingly
  • Keep a master record of median job runtimes
  • Calculate the job load factor: total number of seconds job execution time on an instance on a day, divided by 86,400 (number of seconds in a day).
  • Always favor standard imports over customizations to modify objects.
  • Design impex jobs so that they recover automatically by recognizing which files haven't been imported yet during subsequent execution.

Monitor search indexing for best Practices

Make sure that your search indexes use best practices:

Troubleshooting Performance Problems

Database transaction issues are not a common problem. If you experience a performance problem with your storefront, there are several other areas you might want to check before looking at the Object Churn Trends report.

Gathering Data Before Entering a Ticket:

Identify changes to your code or data to narrow down the possible causes of the problem:

  1. Is the problem reproducible or intermittent?
  2. If reproducible, what are the steps to reproduce?
  3. Did any of the following happen right before the performance issues started:
    • replication of data
    • manual editing of data on the Production instance
    • manual clearing of the cache or a cache partition on the Production instance
    • import of a large data feed
    • replication of code

Is the Issue Network-Related?

Check the following issues and record the answers for communication with technical support:

  1. Is the slowness seen by a single user, a specific location, or is it seen sporadically across the regions?

  2. Are you seeing slowness only on the B2C Commerce storefront or on other internet websites?
  3. Is this slowness common across all instances or seen for a particular instance?
  4. Is the slowness reported for a specific page, search result, component or across the site?
  5. Is the slowness reported by an actual user or by a monitoring bot?
  6. Is the issue seen all the time or happening sporadically?
  7. Is the issue happening at a specific time of day?
Note: If the issue is only seen from a specific location or the whole Internet is slow then it's highly likely to be local network issue.
Steps that can be taken to verify a network issue:
  1. Check for a browser proxy: If the issue is in Mozilla, click Tools > Network > Settings and set it to No Proxy, restart the browser and try accessing the site again. If it doesn't resolve the issue, then contact your network administrator.
  2. Perform a traceroute: This can identify the bottleneck in your network chain. If using Windows then click Start > Programs > Accessories > Command Prompt and then type:
    tracert <B2C Commerce site>
  3. Firebug analysis: Use the network view to do analysis of requests with long response times.
    • Waiting Time: If you see this time to be highest then most probably the issue is on the server side and needs further investigation from a code perspective.
    • Receiving: If this takes the majority of time in the graph then this is a good indication of a local network or browser issue.
    • Connecting: If a request shows huge time spent here then this also is a good indication of a possible network issue.

Is It a Caching Issue?

Cache clears can lead to suboptimal performance during high traffic.

What Can Cause a Cache Clear?

  • Code Replication/Activation Data Replication cause a cache clear unless you specify in the job that they shouldn't. If the cache isn't cleared, however, replicated data isn't shown on the storefront until pages normally refresh their cache.
    Note: Unlike most other type of data replication, geolocation data and coupons don't clear the cache.
  • Manually clearing the cache
  • iscache tags of type „daily“ in your storefront pages clear all pages of a specific type at the same time every day

Common Caching Mistakes:

  • Invalidating cache just before an expected sales peak
  • Invalidating cache several times throughout the day just to bring a specific product or small number of changes online. If this is a frequent scenario, you might want to investigate page cache partitioning.
  • Invalidating page cache just to bring a piece of static content online

Is It a Server-Side Issue?

Performance can be affected by a range of issues, from an expensive storefront script, to frequent running processing-intensive jobs.

  1. Have new code or features been deployed?
  2. Have any site or global preferences changed?
  3. Have there been any recent changes to catalogs or integrations?
  4. Have there been any changes to promotions, slots or content assets?

Examining pipeline and script Performance

Use Pipeline Profiler to identify the most expensive pipeline and the most expensive component within that pipeline. You can drill down into script data within a pipeline to identify expensive scripts running on the storefront.

You can also look at the pipeline technical reports to identify which recent code deployments are related to performance issues. If you determine that a new script or pipeline was recently deployed, you can roll back the code using a code replication of type Undo or by changing the active version in production. See Using Pipeline Profiler.

Examining database performance

Use the object management technical report for insight into database object transactions in B2C Commerce. This report is available to view by selecting (on a Production instance): Administration > Analytics > Object Churn Trends Report.
Note: Unlike other technical reports, which are based on statistics per site, the Object Churn Trends report is based on statistics for all sites on the Production instance.
The Object Churn Trends reports are most useful in showing trends in database transactions. You can use these reports to monitor the performance of new code pushed to your Production instance and to troubleshoot:
  • concurrency issues that cause database deadlocks
  • misuse of session data

Related Links

Troubleshooting

Site Performance

Best Practices for Improving Site Performance

Tools for Improving Site Performance