Russ, As Jeff points out lack of available threads could be a factor flow slower processing times but this would manifest itself by you seeing that the processor isn't running very often. If it is that the process itself when executing takes much longer than on the other box then it is probably best to look at some other culprits. To check this out you can view the status history and look at the average number of tasks and average task time for this process. Does it look right to you in terms of how often it runs, how long it takes, and is the amount of time it takes growing?
If you find that performance of this processor itself is slowing then consider a few things. 1) Does it maintain some internal state and if so is the data structure it is using efficient for lookups? 2) How does your heap look? Is there a lot of garbage collection activity? Are there any full garbage collections and if so how often? It should generally be the case in a well configured and designed system that full garbage collections never occur (ever). 3) Attaching a remote debugger and/or running profilers on it can be really illuminating. JOe On Mon, Oct 3, 2016 at 11:26 AM, Jeff <jtsw...@gmail.com> wrote: > Russel, > > This sounds like it's an environmental issue. Are you able to see the heap > usage on the production machine? Are there enough available threads to get > the throughput you are observing when you run locally? Have you > double-checked the scheduling tab on the processor config to make sure it > is running as aggressively as it runs locally? > > I have run into this sort of thing before, and it was because of flowfile > congestion in other areas of the flow, and there were no threads available > for other processors to get through their own queues. > > Just trying to think through some of the obvious/high level things that > might be affecting your flow... > > - Jeff > > On Mon, Oct 3, 2016 at 9:43 AM Russell Bateman < > russell.bate...@perfectsearchcorp.com> wrote: > >> We use NiFi for an ETL feed. On one of the lines, we use a custom >> processor, *VelocityTemplating* (calls Apache Velocity), which work very >> well and indeed is imperceptibly fast when run locally on the same data >> (template, VTL macros, substitution fodder). However, in production it's >> another matter. What takes no time at all in local runs takes minutes in >> that environment. >> >> I'm looking for suggestions as to a) why this might be and b) how best to >> go about examining/debugging it. I think I will soon have remote-access to >> the production machine (a VPN must be set up). >> >> Thanks, >> >> Russ >>
