Signals Notebook: Parallel Experiment Performance Troubleshooting Guide

Audience and Scope
• Audience: Administrators, Support engineers, and power users working with Parallel Experiments in Signals One.
• Applies to: Parallel Experiments and sub-experiments created and managed via Signals Configuration and the Parallel Experiment feature set (activation, templates, sub-experiments).

Purpose
• Provide a structured, neutral but Signals-aware workflow to diagnose and address slow load, navigation delays, or rendering issues in Parallel Experiments.

Typical Performance Symptoms
• Slow loading of experiments with parallel experiment tables or enumerations.
• Delays when switching tabs that contain samples, subexperiments, or attachments.
• Long rendering times for tables, structures, or file previews.
• Performance differences across users, regions, or networks.

Before You Begin (Initial Problem Verification)
• Collect the experiment URL or reference.
• Capture browser type/version and operating system.
• Ask the user to describe where and when delays occur.
• Identify whether the issue affects specific users, groups, or all users.

Comparative Testing Across Users and Locations
• Test from different geographic regions when applicable.
• Test using different user accounts on the same experiment.
• Compare behavior between Parallel Experiments and standard experiments.
• If applicable, check behavior across different tenants/environments.

Local Browser and System Checks
• Test in an incognito/private window to eliminate extensions.
• Ensure the browser is up to date.
• Check local CPU and memory usage during experiment loading.
• Test on/off VPN or alternative networks when possible.

Collect Evidence: Network Traces and Screen Recordings
• Use browser developer tools to capture HAR files while loading the experiment (enable “Preserve log”).
• Save the HAR after the page fully loads.
• Capture short screen recordings highlighting perceived delays.

Analyze HAR Files (High-Level)
• Look for unusually long API/server response times.
• Identify duplicate or repeated calls to the same endpoint.
• Check overall concurrency and number of parallel requests.
• Compare slow-user HAR files with fast-user HAR files when available.

Review Experiment Structure and Configuration
• Determine whether large data (big tables, many subexperiments, large/num­erous attachments) is concentrated on a single tab.
• Check whether previews (e.g., attachments, structures) are loading during initial render.
• Review any templates/configurations that could trigger extra processing.
• Signals context: Parallel Experiment templates include a Subexperiment Summary table that aggregates subexperiments; large subexperiment sets will surface in this summary construct.

Isolate Performance Contributors
• Create or request a baseline (copy) of the experiment.
• Add elements incrementally (enumeration, samples, attachments).
• Measure load times after each step.
• Move attachments to a separate tab to test the impact of previews.

Common Root Causes and Mitigations
• Excessive data density on a single tab → distribute content across logical tabs.
• Large or numerous attachments → move to a dedicated “Attachments” tab to defer previews.
• Browser/machine resource constraints → close heavy applications or test on a higher-spec machine.
• Network latency or cross-region access → test alternative routes (e.g., off VPN).
• Signals constraint to consider: Parallel Experiments enforce a 1000 compound/sub-experiment enumeration limit; attempts to exceed this can affect usability and outcomes. Plan enumerations accordingly or split runs to remain within supported limits.

Recommendations for End Users
• Organize experiment content across tabs; avoid placing many large files in the main working grid.
• Archive or split oversized experiments when feasible.
• When opening support tickets, report detailed timing, steps to reproduce, user/region scope, and include HAR/screen recordings (when permitted).

Escalation Checklist for Support Teams
• Clear problem summary and precise steps to reproduce.
• Scope of affected users/regions and comparative test results.
• HAR files and screen recordings.
• Experiment size details (enumeration size, number of subexperiments, attachments).
• Any template or configuration details relevant to Parallel Experiments (e.g., presence of large Subexperiment Summary tables).

Related Knowledge and Signals Context
• Activating the Parallel Experiment Feature (overview, activation steps, and considerations for rollout) .
• Parallel Experiment Templates and the Subexperiment Summary table (Admin guide content).