[
https://issues.apache.org/jira/browse/NIFI-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Moser updated NIFI-2996:
--------------------------------
Description:
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?
was:
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, 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?
> 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
>
> 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)
