Michael Moser created NIFI-2996:
-----------------------------------
Summary: 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: 0.7.1, 1.0.0
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, 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)
