Ability to avoid capturing large respones and requests

[LordMike]

Hi again,

I was on my way to fork this repo, and add the missing constructors for the ProfiledElasticClient and friends, when I noticed the reason you only have the one constructor is it's the only way you can force-enable DisableDirectStreaming(), which in turn is required to make the profiler addon useful beyond "yes, a request happened".

But it got me thinking. The first request I profiled with this library was immensely huge (partly why I wanted to profile it). So the miniprofiler UI was sluggish as it rendered the N requests I had made in their full length.

There are currently no options to this library to tweak this (from what I gather).

So I suggest the ability to:

• Via configuration, being able to choose between: Capture only requests, requests+responses (default) or capture only responses, capture nothing.
• The only-requests, only-responses and capture nothing options could collapse the non-captured parts to a "NNN bytes" string
• In practice, the capturing still happens, but this plugin will only render the parts chosen
• A constructor that accepts preconfigured settings - so that the user will have to enable DisableDirectStreaming to take full benefit of the plugin. If it's not enabled, it would be like setting capture nothing (still providing timings - and possibly sizes? .. iirc ES had a bytes-sent/received value somewhere).

[romansp]

Thanks for suggestion @LordMike. As you correctly mentioned this library does very little. It just enables DisablingDirectStreaming, filters some data and pushes audit info from Elastic to MiniProfiler. That's it. Just a tiny bridge. When I initially started this project - that was more than enough for my use case.

Unfortunately I moved on to other projects and don't use this library anymore myself. But I can see how feature you're suggesting will be valuable.

With that being said pull requests are more than welcomed. Especially from devs who use MiniProfiler and Elastic heavily and know exactly what/how they want to see their profiles.

I may find some time to work on that in the future (after fixing #12 and releasing v7) but don't take it as a promise.

[LordMike]

Great. :)

Will see if I can devote some time to it - it's neat to have.. :)
I'm about turned around with our own setup so we can embed this :)

[romansp]

Decided to stop calling DisableDirectStreaming by default as with new DiagnosticListener configuration we don't have direct access to elastic config anyway.

Now it's developer's duty to disable direct streaming if full request/response traces are required.