Recommendation for on-demand profiling

[Piedone]

I'd like to start profiling only from the Azure Portal, either with the "Profile now" button or via triggers. Until then, the profiler should be dormant, and don't affect the app's normal operation in any way. How is this possible to achieve?

It seems to me that just by adding the profiler package you make it start on app start (as evidenced e.g. by the "StartProfiler triggered." log entry). I see the InitialDelay and IsDisabled configuration options but those don't really cover this.

My app is running in Azure App Services under Linux if that matters. I thought about having a custom configuration in my app to enable profiling (basically an if (profilingEnables) around services.AddServiceProfiler();, with an app restart) but that needs to be set separately from the button click. So, I figured there should be a better approach.

Thank you!

[xiaomi7732]

Hey @Piedone Thanks for the discussion. I wish I had the magic button for you :-).

Seriously though, it sounds like it is the first time profiler that is unwanted, do I understand it correctly? Would it work if there's an option to disable it?

For example:

....AddServiceProfiler(opt => {
    opt.EnableOneTimeScheduler = false; // so that the very first-time profiling won't happen.
});

[xiaomi7732]

@Piedone Thanks for the clarification. Yes, I did mean the actual profiling. I thought that was the biggest overhead. The rest of it is kind of minimal.
Now, I see what you are referring to. That is interesting. But I am afraid that I give out wrong suggestion without understanding more details. So, do you mind explain to me, what is the major concern? Is it CPU overhead, memory usage or network traffic? And how are those impact the running application?

[Piedone]

OK, thank you, it's reassuring to know that there shouldn't be any significant overhead.

My main concern is that there's something going on in my app continuously that I don't control, don't know in detail, and I only actually need rarely. This impacts operations with a component that I don't control, potentially performance, security, and as you say possibly also network traffic and log ingestion (with its cost impact).

I didn't measure the performance or any other impact (my first trouble was to get profiling to work), nor have anything concrete at this time. I'm just generally wary of adding a rarely used component that's so active that it can log something every second on average. I'd similarly not keep remote debugging enabled, for example, even if it would have no performance impact.

Do I understand that at this time the best option is to go ahead with an if (profilingEnabled) around services.AddServiceProfiler();? While not necessarily ideal, I'm OK with that, I just opened this thread with the hopes that there was something better.

[Piedone]

Would you be so kind to confirm this, @xiaomi7732?

[xiaomi7732]

Sorry for the delay @Piedone, I see what you mean now.
Yes, you can do that.

Another option for you (you mentioned it earlier) would be to set profiler to disabled. And when you find out that you need it, you can overwrite the settings.

For example, you could start by set an environment variable:

ServiceProifler__IsDisabled=true

And when you need it, simply flip it to

ServiceProifler__IsDisabled=false

When set to disable, this should disable all the services in this package. Are you seeing different?

[Piedone]

Thank you, but in the meantime we've gone with the if (profilingEnabled). It works (naturally) and is not too big of an issue. If we already have to flip such a switch, it doesn't really matter if it's this one or a built-in one.

But anyway, due to #247 we'll eventually migrate to OpenTelemetry and the Azure Monitor OpenTelemetry Profiler (Lombiq/Open-Source-Orchard-Core-Extensions#1246).