Max Statements and general recommendations for limits

[niemyjski]

Is your feature request related to a problem? Please describe.

It would be nice if there was a general recommendations around the limits and further discussing how limits are calculated and how they are cleaned up / decremented.

Describe the solution you'd like

A clear and concise description of constraints and some general guidances / load / memory usage (I get that every consumer is a bit different)

Describe alternatives you've considered

Looked through code via search, didn't see anything clear cut.

[niemyjski]

Also, it would be really nice to have hooks / tracing / metrics so one could reasonably see various counts to make better decisions.

[lahma]

You can see some test cases here which validate the functionality. I'm afraid it's quite hard to give any general advice as every use case is different, you might not even need the constraints if you run trusted code. For tracing and hooks you could probably but your own constraint or hook to debugger support to generate information to support you decisions.

[niemyjski]

Thanks, I was hoping to figure out how to get current counters outputted to open telemetry so I could see what my current limits and growth looks like. I have to have limits for user defined JavaScript :-)

[lahma]

Maybe it would be just easiest to copy the relevant constraint logic to your own and then output stats (reached max values) on every Reset call, reset is done before and after script execution.

[niemyjski]

Would you be open to a pr that adds support for activity? https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.activitysource?view=net-8.0

[lahma]

Direct built-in support could be problematic when it comes to new dependencies and by default such feature should have zero performance impact.

[niemyjski]

@lahma we took a deeper look into this and I agree it should stay out of the library. We ran into some pain points around collecting this data.

1. When we call execute all constraints / limit counters are reset when the value is returned, so there is no way for us to know how many statements our scripts are running into. It would be nice if there was a call back or a way to get this information in a thread safe way.
2. We are seeing unbounded growth of the engine when we call execute with named functions. There really is no visibility to tell current memory or how many scripts are registered (we kind of naming our scripts like functionName_uniquetenantid.