Troubleshooting Salesforce B2C Commerce Performance

Use the object management technical report, pipeline profiler, and other analytic tools to monitor deployed code and identify or prevent performance problems. When a performance issue occurs, you can take several steps to identify the cause 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 new B2C Commerce version, monitor performance to see if the new code affected it. You can use the Pipeline Profiler. 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

Monitor Job Runtimes

Monitor job runtimes regularly. Analyze any jobs running over one hour to identify possible optimizations.

Make sure that your data import follows 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).
When modifying objects, always favor standard imports over customizations.
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 follow best practices:

Avoid running full index rebuilds. Instead, rely on incremental indexing to keep data fresh. To avoid fragmentation over time, use full-index rebuilds sparingly.
Replicate product data indexes from staging to production

Troubleshooting Performance Problems

Database transaction issues are not a common problem. If your storefront experiences a performance problem, you can check several other areas before entering a ticket.

Gathering Data Before Entering a Ticket:

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

Is the problem reproducible or intermittent?
If reproducible, what are the steps to reproduce?
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:

Is the slowness seen by a single user, a specific location, or is it seen sporadically across the regions?
Are you seeing slowness only on the B2C Commerce storefront or on other internet websites?
Is this slowness common across all instances, or restricted to one instance?
Is the slowness reported for a specific page, search result, component or across the site?
Is the slowness reported by an actual user or by a monitoring bot?
Is the issue seen all the time or happening sporadically?
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:

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.
Perform a traceroute: It 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>
```
Firebug analysis: Use the network view to do analysis of requests with long response times.
- Waiting Time: If waiting time is highest in the graph, then the issue is most likely on the server side and the code needs further investigation.
- Receiving: If receiving time is highest in the graph, then the issue is probably with a local network or browser.
- Connecting: If a request spends a long time connecting, it often indicates a 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, code activation, and data replication clear the cache unless you specify not to in the job. If the cache isn't cleared, however, replicated data isn't shown on the storefront until pages refresh their cache normally.
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 that happens frequently, investigate page cache partitioning.
Invalidating page cache just to bring a piece of static content online

Is It a Server-Side Issue?

A range of issues can affect performance, from an expensive storefront script to frequent processing-intensive jobs.

Have new code or features been deployed?
Have any site or global preferences changed?
Have there been any recent changes to catalogs or integrations?
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 a new script or pipeline was recently deployed, you can roll back the code. Use a code replication of type Undo or change the active version in production.