Table of Contents

Performance debugging

How to identify performance issues on a DynamicWeb solution

In most cases, bad performance is defined as the frontend having a high response time - e.g. search, adding to cart, or maybe showing the product list takes longer than it should. The reason for this can be anywhere from bad implementation, over memory leak in standard/custom code, and to a server with insufficient resources (memory and/or cpu). Most of the time it is due to a single, and not multiple problems.

A good place to start out is to try answering some of the following questions:

  • When did the issue start? Determining when the problem began can provide clues about potential causes, such as recent changes or updates.
  • Has anything changed recently? Consider recent version updates to the website, server configuration changes, changes in traffic volume, or updates to third-party services/plugins.
  • Are there any specific pages or components experiencing significant issues? Identifying specific areas of the website that are under-performing can help focus troubleshooting efforts.
  • Has website traffic gone up significantly? If the website suddenly attracts a lot of visitors, e.g. due to a Black Friday or Christmas discount campaign, you may experience performance issues due to the increased traffic.
  • Is there a performance difference between frontend and backend rendering? This can point in the direction of whether this is implementation, integration or server related.
  • Is the site updated by and/or depending on an external feed? If you connect to an external feed it might be the source of performance issues.
  • Are there any integration connections problems? An integrated solution with performance issues may experience problems related to network and endpoint issues.

Once you've answered these questions you will be better equipped to start the debugging process.

Browser developer tools

Start low-key: what does the browser console tell you? Using the standard developer tools in the browser often times helps identifying which calls to the system that have high load times.

Built-in DynamicWeb performance monitoring tools

DynamicWeb 10 ships with a number of built-in performance monitoring tools which can be used to analyze and identify potential bottlenecks:

DynamicWeb also features some useful URL parameters which you can add to a page url to see what's going on:

  • debug=true shows extensive trace information like load times, page stats, SQL statements
  • dbstat=true shows all database-calls, including executing time

Event Viewer

The Event Viewer is a tool which provides you with a structured overview of system events recorded by DynamicWeb - both error, warning, and information-level events.

In a debugging context it functions as a control panel which tells you where to look and what to fix.

When you use the Event Viewer:

  • Look for repitition as an indicator for a misconfiguration or missing ressource - a single error can be incidental, but the same error ocrurring every minute is a problem
  • Group by action or category to quickly see which subsystem is unhealthy - for instance Scheduling, Database, URLResolve, Tracking
  • Fix the cause, not the symptom - deleting events does not solve problems, so you need to figure out why it happens

Instead:

  1. Identify the recurring event
  2. Inspect the associated log file
  3. Fix configuration, code, or data
  4. Confirm that new events stop appearing

On a healthy system:

  • Errors are rare
  • Warnings are intentional and understood
  • Informational logging is temporary

Health Checks

Bad data rarely stays isolated - for example:

  • Orphaned records increase table sizes without providing value
  • Broken relations trigger repeated errors during rendering or indexing
  • Circular references lead to unexpected behavior or excessive processing
  • Missing defaults cause fallback logic to run repeatedly
  • Dead data prevents effective caching and cleanup

Often, these issues will resurface as problems later on such as excessive logging, repeated errors in the Event Viewer, slow admin tools, and worst of all sluggish frontend behavior under load.

To help combat bad data and help avoid performance issues, DynamicWeb features a Health-section which provides an at-a-glance overview of the structural and data integrity of a Dynamicweb solution. That is to say it checks for broken or inconsistent data and configurations. These health checks can be used as a starting point for an investigation.

Health checks are especially useful when:

  • A solution behaves inconsistently
  • Errors keep reappearing after "fixes"
  • Performance slowly degrades without obvious changes
  • Database size grows unexpectedly
  • You inherit or upgrade an older solution

A recommended investigation flow:

  1. Review the reports found under each Health-section
  2. Identify checks in Warning or Error
  3. Inspect affected records
  4. Fix or remove invalid data
  5. Re-run the check
  6. Observe whether related errors disappear from the Event Viewer

Where the Event Viewer shows runtime consequences, the Health-area reveals potential structural problems.

Scheduled tasks

Scheduled tasks may also be a source of performance issues:

  • Are all the necessary Scheduled task running or has any of the stopped working?
  • Check if performance problems happen while executing scheduled tasks.
  • Also check if you may have multiple task that run on top of each other, putting the site under pressure.

Integration

When an integrated solution experiences performance issues, it may be an idea to see if the integration is the source.

This can be done by creating a copy of the website, disable the integration, and testing performance again.

Customizations

In our experience, custom functionality is often a source of performance issues. We recommend that you check if this is the case:

  • Create a copy of the solutions
  • Remove all custom DLL files
  • Test performance again

If this fixed the issue, your customizations may be the source of your performance issues.

Security

Is the site running a recommended and updated version. Notice that a performance issue could be due to a momentary DDOS attack. Contact your Hosting company if you expect this is the reason.

Hosting

Also evaluate if the server has enough resources by looking at performance. Contact the hosting company if you are unsure if this is the bottleneck. Ensure that database server and IIS is configured with enough resources (CPU, memory). Are there any Security scanner running during performance issue. If you have access to the Web and SQL server, use tools like SQL Server Profiler and event viewer for analyzing. A potential SQL bottleneck for query performance is when you are searching on a column that is not part of an index. Make sure that tables have an index.

Optimization

If it is not a specific problem, then try general site optimization using external tools for example:

  • Google Performance Insights
  • Google Lighthouse
  • New Relic
  • GTmetrix

Log retention policies

While logging itself is usually lightweight, large volumes of historical logs are not:

  • Large database log tables:
    • Increase index size
    • Slow down queries and maintenance jobs
    • Increase backup size and restore time
  • Large log files:
    • Consume disk space
    • Slow down file access and log rotation
    • Make diagnostics harder, not easier

You should therefore use the log retention settings to automatically clean old logs from the system. While log retention policies does not reduce overhead directly, it prevents secondary performance issues caused by an accumulation of log data. In other words, log cleaning prevents logging from becoming a long-term performance issue.

Templates

  • Slow Template time rendering. Optimize template logic by reducing unnecessary computations, minimizing the use of loops and conditionals, and caching frequently accessed data where possible.
  • Database Queries in Templates: Minimize database queries within templates by pre-fetching and passing data to templates in a structured format. Use Lucine Indexing when possible.
  • Resource Loading and Dependencies: Minimize the number of external resource requests by combining and minifying CSS and JavaScript files. Utilize content delivery networks (CDNs)
  • Lazy loading Employ lazy loading techniques for non-critical resources to prioritize rendering and content delivery.

Investigations

For complex issues requiring in-depth analysis, our Support-team may elect to initiate investigations to identify and resolve issues. Investigations are typically conducted in collaboration with Product Development.

Improve this doc
To top