[
https://issues.apache.org/jira/browse/NIFI-9309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433384#comment-17433384
]
ASF subversion and git services commented on NIFI-9309:
-------------------------------------------------------
Commit 5766d33fce1093fc4c532a684bc1d2e8410b09c4 in nifi's branch
refs/heads/main from markap14
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=5766d33 ]
NIFI-9309: Include a uiOnly flag when requesting flow for a given pro… (#5462)
NIFI-9309: Include a uiOnly flag when requesting flow for a given process
group. In that case, do not include the property descriptors, property values,
etc. for Processors. When fetching Variable Registry, improved logic to cache
the VariableImpact for each property value instead of parsing/recreating it
every time. When fetching bulletins for a component, avoid filtering through
all components' bulletins and instead only look at bulletins that might pertain
to the appropriate component
> Improve UI responsiveness
> -------------------------
>
> Key: NIFI-9309
> URL: https://issues.apache.org/jira/browse/NIFI-9309
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Core UI
> Reporter: Mark Payne
> Assignee: Mark Payne
> Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> There are a few different small improvements that can be made to the backend
> that will result in far better UI performance in some situations:
> * Include a uiOnly query parameter when the request is made to fetch the
> flow for a ProcessGroup. This can filter out specific fields such as
> processor properties & property descriptors. If the UI passes in this query
> parameter, we can avoid populating much of the DTO objects. This means the
> request is much smaller so in a cluster, it's much less to
> deserialize/parse/serialize when merging responses, and it means that the UI
> has a lot less json to parse.
> * When attempting to access the Variable Registry for a given Process Group,
> we are very inefficient in how we determine which components are affected by
> a given variable. Instead of re-compiling the Expression Language for every
> property, we should do it only once and make that a part of the
> PropertyConfiguration object and make use of that.
> * When obtaining the bulletins for a given component, we are also very
> inefficient. We iterate over many RingBuffer objects, filtering entities for
> each. But if we know the component & process group ID of the component whose
> bulletins we are interested in, we can instead just jump straight to the
> appropriate RingBuffer by fetching it from the Map.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
