-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[HttpKernel] Add Profiler::isEnabled() method #45265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
2063db8
to
c3b08e8
Compare
Hey! I think @mtarld has recently worked with this code. Maybe they can help review this? Cheers! Carsonbot |
If I get it right, the "collaborating services" will depend on the Alternative proposition : propagate status to the collectors when |
This has nothing to do with collectors.
…On Wed, 2 Feb 2022, 07:37 Jérôme Tamarelle, ***@***.***> wrote:
If I get it right, the "collaborating services" will depends on the
profiler service, which is not needed currently. You don't get a circular
depencency (profiler -> collector -> collaborating service -> profiler) ?
Alternative proposition : propagate status to the collectors when
Profiler::disable() is called.
—
Reply to this email directly, view it on GitHub
<#45265 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADS4YQOR6R6E7HS77YZR6LUZDNLXANCNFSM5NIVTLCA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Well, could you describe your use-case a little more. What is a "collaborating service that collect profiling data on behalf of those collectors" ? |
Sure. I wrote a database profiler similar to the one you know in Doctrine, but for the Amp drivers instead (see also: doctrine/DoctrineBundle#1464). The regular connection pool is decorated with a profiled pool; this is the collaborating service. This service is injected into the collector. When the profiler is disabled the collector will not be called, but the pool is still decorated and still collects data anyway, since it is unaware of the status of the profiler. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the details.
I have almost the same use-case and used %kernel.debug%
to enable/disable collection of queries in the client decorator. Your solution is smarter.
Regarding circular dependency, the container builder is able to handle it.
This comment was marked as off-topic.
This comment was marked as off-topic.
Can this be included in 5.4 somehow? |
No, new features are always merged on the upcoming branch. |
Thank you @Bilge. |
eb7de7a
to
b305386
Compare
When disabling the profiler programmatically, collectors will not be called, but any collaborating services that collect profiling data on behalf of those collectors will still do unnecessary work. By being able to inquire about whether the profiler is enabled, such services may elect to omit data collection thus reducing memory and CPU footprint.
Relates to #45241.