Open StephenOTT opened 1 year ago
Hi @StephenOTT,
Thank you for reaching out to us with this. Could you elaborate a bit more on the goal and purpose of a such metric.
I will have a look at the request and get back to you. Please note that there might be some delay in the processing due to other team's responsibilities. Thank you for your understanding.
Best, Yana
@yanavasileva building on the scenario from #3120; bpmn parsing is an expensive task and thus definitions are cached. But this caching is not visible / reportable in the metrics. If an instance of the bpm application has more definitions than cache space, then the eviction/re-caching is not visible. It leads to gremlins in the system, trying to identify why SELECT queries are slow (such as loading a user's tasks), but internally there is a large amount of BPMN re-parsing/caching occurring.
Having the caching metric would allow administrators to set alerts for when re-caching is frequent and provide justification for increasing cache limits.
Hi @StephenOTT ,
Thank you for your reply. We consider your request can be a useful addition to Camunda, but we will not be able to work on this any time soon. We encourage you to make a code contribution.
Please note, I adjusted the description of the ticket with a technical requirement, the metric needs to be with opt-in behaviour. The size of the Metrics database table is a concern for some users, so everyone can decide whether to enable the metric in their system or not.
Best regards, Yana
User Story (Required on creation)
due to scenarios as outlined in https://github.com/camunda/camunda-bpm-platform/issues/3120, a new Metric should created that logs the frequency of re-caching.
Functional Requirements (Required before implementation)
Each time the cache has an insert, +1 should be added to the Metric. Similar behaviour to how DMN eval instances are logged in the metrics.
Technical Requirements (Required before implementation)
Limitations of Scope
Hints
Links
Breakdown
Dev2QA handover