[
https://issues.apache.org/jira/browse/NIFI-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655470#comment-15655470
]
ASF GitHub Bot commented on NIFI-2996:
--------------------------------------
Github user mosermw commented on the issue:
https://github.com/apache/nifi/pull/1192
Very good points @mcgilman. Just by numbers, there are more processors than
services/tasks/ports, but I agree they should all act the same. It's possible
that only the getValidationErrors() has significant effect on REST request
performance. I will do more experiments and update this PR.
I really wanted this PR to have minimal changes, because I think NIFI-950
(background asynchronous validation when validating **everything** for the UI)
is a better approach.
> Processor/Service validation takes exponentially longer to run as the graph
> grows
> ---------------------------------------------------------------------------------
>
> Key: NIFI-2996
> URL: https://issues.apache.org/jira/browse/NIFI-2996
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 1.0.0, 0.7.1
> Reporter: Michael Moser
> Assignee: Michael Moser
> Fix For: 1.1.0
>
>
> As you add processors that reference controller services to your NiFi, the
> validation that occurs during normal UI usage increases dramatically.
> When running in a cluster, I have to increase the nifi.properties
> nifi.cluster.node.read.timeout well beyond its 5 sec default timeout in order
> for the UI to work. Eventually, simple operations in the UI take close to a
> minute to happen.
> As a test, I created an SSLContextService using certs created with the
> amazingly useful nifi-toolkit. I created a DistributedMapCacheClientService
> that references this SSLContextService. Then I created 108
> FetchDistributedMapCache processors that reference the
> DistributedMapCacheClient service. I used ${hostname(true)} for my
> FetchDistributedMapCache processor's Cache Entry Identifier property.
> When NiFi is up with no UI connected, during a single "NiFi status" phase I
> noticed that the SSLContextService was validated 108 times and the EL
> hostname(true) was evaluated 216 times. When I connect the UI and go through
> a normal status refresh cycle, the SSLContextService was validated 432 times
> and the EL hostname(true) was evaluated 864 times. These validations take a
> full second on my slowest machine.
> In NiFi 0.x, the expensive REST API call is
> /nifi-api/controller/controller-services/node.
> In NiFi 1.x, it appears to divide the work among REST API calls to
> /nifi-api/process-groups/UUID and
> /nifi-api/flow/process-groups/UUID/controller-services and
> /nifi-api/flow/status
> Rather than attempting to fix StandardSSLContextService or the EL
> HostnameEvaluator, I wonder if there was a more generic approach to helping
> resolve this?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
