Profiler

Opening a Saved Profiler Session

Learn how to open and inspect a saved Symfony profiler capture, review collector panels, handle compatibility failures, and protect sensitive diagnostic data.

A profiler is a diagnostic tool that records information about an application's execution, requests, performance, and related subsystems. A profile is one recorded diagnostic snapshot or report. The stored data used to rebuild that report is a profiler capture.

This lesson explains how to open an existing capture through the profiler interface, especially the Symfony WebProfiler-style interface. The exact controls and supported formats depend on the installed Symfony and WebProfiler versions.

What the Open profiler screen does

The Open screen loads an existing profiler capture so you can inspect it. It does not normally collect a new profile for the request that is currently in your browser.

• Opening a capture: reads previously stored or exported diagnostic data and reconstructs a report.
• Collecting a profile: runs a request or command with profiling enabled and records new data.

Opening is useful when a teammate sends you a supported capture, when you retain a profile from an earlier environment, or when you need to revisit a slow or failing request without reproducing it immediately.

In the Symfony-style interface, the Open page is available at /_profiler/open/. The route may be unavailable, protected, or implemented differently if your framework or WebProfiler version changes. Some versions accept a local file or exported capture through the page; others only open captures available through their configured profiler storage. Treat the controls displayed by your installed version as authoritative.

Capture sources and formats

Profiler implementations can store different kinds of data. A capture might represent an HTTP request, a console command, or another instrumented execution. Depending on enabled integrations, it may contain request metadata, timing information, database activity, logs, events, cache operations, exceptions, or memory measurements.

Common sources include:

• Local profiler storage maintained by the application.
• An exported file produced by the profiler or an approved diagnostic workflow.
• Output from a command-line profiling tool.
• Another approved source supplied by a developer, operations team, or support process.

Supported formats are not universal. They depend on the framework, WebProfiler version, storage implementation, enabled integrations, and the tool that created the file. A raw performance trace is a chronological execution record, often focused on timing and call relationships. It is not necessarily a profiler capture and may require a specialized trace viewer.

Opening a saved capture

1. Confirm that the capture came from an approved source and that its format is supported by your profiler version.
2. Open the profiler's Open page. In this Symfony-style lesson, use /_profiler/open/.
3. Select or supply the capture using the controls provided. Depending on the version, this can mean choosing a stored profile, entering an identifier, or selecting an exported file.
4. Submit the form or activate the equivalent open action.
5. Wait for the profiler to parse the capture and navigate to the resulting report.

A successfully opened report should expose the same applicable panels that would be available for a normally collected request. “Applicable” matters: panels depend on what was collected and which integrations are installed and enabled.

Confirming that the intended profile loaded

Before interpreting the results, verify that the report belongs to the intended execution.

• Check the request method, path, host, status code, and environment when those fields are available.
• Compare the displayed timestamp or duration with the incident or test that produced the capture.
• Look for an exception message, request parameter, command name, or other identifier that distinguishes the capture.
• Record the profile token or identifier if the interface provides one. A profile token is an identifier used by some profiler interfaces to locate and revisit a collected profile.

Use the token or identifier to revisit the report where supported. Do not assume that a token remains valid forever: retention policies, storage cleanup, environment changes, or access restrictions can make an old profile unavailable.

Reviewing the loaded report

Review the summary first, then move through the panels relevant to the problem. A collector is a profiler component that gathers data for one concern.

• Request metadata: inspect the route, method, status, host, attributes, and environment details.
• Timing: check total duration and the timing breakdown for framework work or external operations.
• Database activity: look for query count, slow queries, duplicate queries, transaction information, and query parameters when exposed.
• Logs: correlate warnings, errors, and application messages with the request timeline.
• Events: identify dispatched events and listeners that may explain unexpected work.
• Cache activity: inspect hits, misses, reads, writes, and invalidations when a cache collector is available.
• Errors and exceptions: review the exception class, message, stack trace, and related request context.

Absence of a panel does not prove that no activity occurred. The collector may have been disabled, the request may not have exercised that subsystem, or the capture may contain only partial data.

Example: reviewing a shared performance investigation

1. Receive a supported capture from a teammate through an approved channel.
2. Confirm its origin, intended environment, and approximate request time.
3. Open it through the profiler's Open interface.
4. Inspect duration, database activity, logs, and exception information.
5. Record findings such as an additional query, a slow external operation, or an exception.
6. Share conclusions without redistributing raw request data or the original capture unless that sharing is authorized.

Example: comparing healthy and problematic requests

1. Open the retained profile for the slow or failing request.
2. Review its timing and available collector panels.
3. Collect or open a separate profile for a healthy request made under comparable conditions.
4. Compare query counts, slow operations, errors, cache behavior, event activity, and memory measurements where available.
5. Separate observed differences from unavailable measurements. A missing collector is not evidence that the healthy request or problematic request had no such activity.

Profile data sources and appropriate use

Security and data handling

Profiler captures are diagnostic data, not automatically safe-to-share reports. They can contain request payloads, headers, cookies, authentication tokens, SQL values, file paths, stack traces, log messages, and user-related data.

Sanitization means removing or masking sensitive information before a capture is stored or shared. Before sharing:

• Remove cookies, authorization headers, API keys, session identifiers, passwords, and tokens.
• Mask personal data in request payloads, query parameters, logs, and database values.
• Remove or restrict stack traces and file paths when they reveal internal implementation details.
• Use an approved transfer location and apply the organization's retention and deletion rules.

Restrict profiler routes and stored captures to authorized development or diagnostic users. Do not expose development or diagnostic endpoints publicly. Production diagnostics must follow the application's security, privacy, access-control, and incident-handling policies.

Example Symfony access control

The following is an actionable Symfony Security configuration pattern. It assumes that the firewall authenticates users and that authorized diagnostic users have the ROLE_DEVELOPER role. Replace that role with one defined by your application.

security:
    access_control:
        - { path: ^/_profiler, roles: ROLE_DEVELOPER }

You can add a network restriction when appropriate, but do not treat an IP restriction as a replacement for authentication:

security:
    access_control:
        - { path: ^/_profiler, roles: ROLE_DEVELOPER, ips: [127.0.0.1, ::1] }

Confirm that the rule is evaluated by the firewall serving the profiler route and test both an authorized and an unauthorized request. The exact role, firewall, proxy, and network policy are application-specific.

Storage and retention configuration

There is no single storage configuration block that applies to every Symfony or WebProfiler version. Storage can be local, service-backed, or supplied by an integration. Do not copy placeholder keys into framework.yaml and assume they are valid.

Start by inspecting the configuration supported by the installed application:

php bin/console debug:config framework profiler

Use the resulting options and the installed version's documentation to identify whether profiler storage, retention, collection, or a storage DSN can be configured. Also check deployment-specific environment variables and service configuration. Set retention deliberately: keeping fewer captures reduces exposure, while keeping enough captures supports the investigation workflow.

Limits and compatibility

An Open operation can fail when a capture is incomplete, corrupted, too large, unsupported, or generated by an incompatible profiler version. A capture may also load successfully but contain less information than expected because collectors or integrations were disabled when it was created.

• A profiler report is structured diagnostic data for a framework profiler.
• A raw trace is a different artifact, usually requiring a trace-specific viewer.
• Disabled collectors cannot provide data retroactively.
• A request that never used a subsystem will not necessarily have meaningful data for that subsystem.
• Different framework, WebProfiler, PHP, or integration versions can change serialization formats and available panels.

Common open failures

Troubleshooting checklist

1. Confirm that you are using the profiler interface intended for the artifact.
2. Check the capture's origin, file completeness, format, and approximate size.
3. Verify compatibility between the capture-producing environment and the current profiler version.
4. Check whether required collectors and integrations were enabled when the capture was created.
5. Ask the original environment for a fresh export if the capture cannot be validated.
6. If the artifact is a raw trace, open it with the appropriate trace viewer rather than the profiler report viewer.
7. Handle all copies as potentially sensitive until sanitization and authorization are confirmed.

Related profiler pages

• Latest profiler profile for inspecting the most recently available profile.
• PHP information for checking runtime details that can affect profiling behavior.