[RFC] Add a way to disable logging and profiler at runtime #60037

lyrixx · 2025-03-25T16:42:35Z

Description

Problem

When I work on long running process I often face the same situation where
Symfony leaks. It usually does not happen in production, but in development it
is a real pain. I have already worked hard on Symfony to mitigate this issue,
but it is still there.

Now, I think the remaining pain point is the Profiler + Logger debug infrastructure.

To ease the debug, we store a lot of information in the profiler and in the
logs.

However, when the process runs for a long time, the profiler and the logs grow
and grow and grow. More over, we usually don't need all that information.

For example, when we import huge CSV, as a developer we does tons of SQL or
HTTP queries.

In the past, we used to "mute" the SQL logger :

$this->connection->getConfiguration()->setSQLLogger(null);

But this does not work anymore since DBAL4. More over, Symfony still collect a
lof a data in the profiler.

There a some workarounds, but they are so not satisfying. And it makes me wonder
if Symfony can't do better.

Proposal

I think Symfony should provide a way to "mute" the profiler and the logger, programmatically.

So I think we could introduce a new interface and its implementation:

interface DebugRecorderInterface
{
    public function disableLogging(): void;
    public function enableLogging(): void;

    public function disableProfiling(): void;
    public function enableProfiling(): void;
}

I think we need to make a difference between the logger and the profiler, because
we may want to disable one and not the other.

For example, in production we want to keep logs (since we usually have a buffer
with eviction) and in dev we want to remove everything.

Example

No response

94noni · 2025-03-25T19:42:34Z

i tend to agree on this for both profiler/logger

just for profiling at runtime in dev, how will it be different from https://symfony.com/doc/current/profiler.html#enabling-the-profiler-conditionally ?

lyrixx · 2025-03-25T21:56:02Z

just for profiling at runtime in dev, how will it be different from https://symfony.com/doc/current/profiler.html#enabling-the-profiler-conditionally ?

this works only with HTTP, not CLI, right?
This is not really handy
It all or nothing, I want more granularity

stof · 2025-03-26T13:34:25Z

Disabling the profiler from collecting data does not directly impact all the traceable decorator services (it will only disabling the fact that we call collect() on the collectors).
Stopping to use memory in traceable services will require altering each traceable services.

The same is true for the logger: it will require a feature in the logger implementation itself to make it a no-op.

nicolas-grekas · 2025-04-18T13:47:36Z

Should be fixed by #60243
Third-party data collectors will need similar changes.

This PR was merged into the 7.3 branch. Discussion ---------- [HttpClient] Improve memory consumption | Q | A | ------------- | --- | Branch? | 7.3 | Bug fix? | no | New feature? | no | Deprecations? | no | Issues | Partially #60037 | License | MIT On the CLI, even if the profiler is not enabled by default, the underlying infrastructure is still in place. In this PR, I'm targeting TraceableHttpClient, which collects requests and responses for nothing. To fix this, I'm adding an "enabled" flag on TraceableHttpClient, so that we can enable the tracing only when the profiler is enabled. In addition, I'm augmenting option `extra.trace_content` so that when disabled, we don't collect request's bodies, which can be huge when uploading. And last but not least, I'm fixing the implementation of curl's debug info collection, which currently relies on allocating new strings all the time instead of reusing the already created zval when debug info didn't change. Commits ------- 0e865e6 [HttpClient] Improve memory consumption

…er][Validator][Workflow] Don't enable tracing unless the profiler is enabled (nicolas-grekas) This PR was merged into the 7.3 branch. Discussion ---------- [Cache][EventDispatcher][HttpClient][HttpKernel][Messenger][Validator][Workflow] Don't enable tracing unless the profiler is enabled | Q | A | ------------- | --- | Branch? | 7.3 | Bug fix? | no | New feature? | no | Deprecations? | no | Issues | #60037 | License | MIT This PR ensures traceable decorators are enabled only if the profiler is also enabled. The way it works is by adding a new argument to all traceable decorators: `?\Closure $disabled`. When a closure is given and when the closure returns true, tracing should be skipped. Calling the closure should be done before every decorated method to cope for dynamically enabled/disabled states. Then, this argument is wired using dependency injection so that a closure is passed that returns the current state of the profiler. If the profiler is not instantiated yet (eg because we're on the CLI, or because we're before ProfilerListener enabled it), then a default state is used (disabled on the CLI, enabled on the web). This allows collecting data on the web even if the profiler didn't start yet (as happens when a request comes in, before ProfilerListener is triggered). Note that I didn't change all `Traceable*` decorators: the remaining ones look inoffensive to me. Of course, this could be wrong and fixed in follow up PRs. Commits ------- d5a3769 Don't enable tracing unless the profiler is enabled

…er][Validator][Workflow] Don't enable tracing unless the profiler is enabled (nicolas-grekas) This PR was merged into the 7.3 branch. Discussion ---------- [Cache][EventDispatcher][HttpClient][HttpKernel][Messenger][Validator][Workflow] Don't enable tracing unless the profiler is enabled | Q | A | ------------- | --- | Branch? | 7.3 | Bug fix? | no | New feature? | no | Deprecations? | no | Issues | symfony/symfony#60037 | License | MIT This PR ensures traceable decorators are enabled only if the profiler is also enabled. The way it works is by adding a new argument to all traceable decorators: `?\Closure $disabled`. When a closure is given and when the closure returns true, tracing should be skipped. Calling the closure should be done before every decorated method to cope for dynamically enabled/disabled states. Then, this argument is wired using dependency injection so that a closure is passed that returns the current state of the profiler. If the profiler is not instantiated yet (eg because we're on the CLI, or because we're before ProfilerListener enabled it), then a default state is used (disabled on the CLI, enabled on the web). This allows collecting data on the web even if the profiler didn't start yet (as happens when a request comes in, before ProfilerListener is triggered). Note that I didn't change all `Traceable*` decorators: the remaining ones look inoffensive to me. Of course, this could be wrong and fixed in follow up PRs. Commits ------- d5a3769bd05 Don't enable tracing unless the profiler is enabled

carsonbot added the RFC RFC = Request For Comments (proposals about features that you want to be discussed) label Mar 25, 2025

94noni mentioned this issue Apr 18, 2025

[HttpClient] Improve memory consumption #60241

Merged

nicolas-grekas mentioned this issue Apr 18, 2025

[Cache][EventDispatcher][HttpClient][HttpKernel][Messenger][Validator][Workflow] Don't enable tracing unless the profiler is enabled #60243

Merged

fabpot closed this as completed Apr 27, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[RFC] Add a way to disable logging and profiler at runtime #60037

[RFC] Add a way to disable logging and profiler at runtime #60037

lyrixx commented Mar 25, 2025

94noni commented Mar 25, 2025

lyrixx commented Mar 25, 2025

stof commented Mar 26, 2025

nicolas-grekas commented Apr 18, 2025