On Thu, Jun 9, 2016 at 2:49 PM, Jonathan Wonders <[email protected]> wrote:
> Hi All, > > I've been tracking down some performance issues on a few 1.6.x > environments and noticed some interesting and potentially undesirable > behavior in the visibility constraint. When the associated visibility > evaluator checks a token to see if the user has a matching authorization, > it uses the security operations from the tablet server's constraint > environment which ends up authenticating the user's credentials on each > call. This will end up flooding logs with Audit messages corresponding to > these authentications if the Audit logging is enabled. It also consumes a > non-negligible amount of CPU, produces a lot of garbage (maybe 50-60% of > that generated under a heavy streaming ingest load), and can cause some > contention between client pool threads when accessing the ZooCache. > > My initial measurements indicate a 25-30% decrease in ingest rate > (entries/s and MB/s) for my environement and workload when this constraint > is enabled. This is with the Audit logging disabled. > > Is this intended behavior? It seems like the authentication is redundant > with the authentication that is performed at the beginning of the update > session. > No. It would be best to avoid that behavior. > > Thanks, > --Jonathan >
