sentry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun Suresh (JIRA)" <>
Subject [jira] [Commented] (SENTRY-178) Poor performance for Sentry Policy Service as #of privileges is scaled up
Date Wed, 21 May 2014 18:21:39 GMT


Arun Suresh commented on SENTRY-178:

Looks like we were doing an extra privilege append on the role inside the SentryStore. The
'privilege.appendRole(role)' already calls 'role.appendPrivilege(privilege)'. 

It Looks like DataNucleus does some byte-code weaving to intercept the append call and tries
to do some other magic.

> Poor performance for Sentry Policy Service as #of privileges is scaled up
> -------------------------------------------------------------------------
>                 Key: SENTRY-178
>                 URL:
>             Project: Sentry
>          Issue Type: Bug
>    Affects Versions: 1.3.0
>            Reporter: Lenni Kuff
>            Priority: Critical
>         Attachments: SENTRY-178.1.patch
> I have observed that as the number of role privileges is scaled up, the performance of
the Sentry Service (time it takes to execute a grant/revoke RPC) gets increasingly worse.
> The following is how long it takes to execute an RPC to grant/revoke a privilege from
a role:
> {code}
> # of Role Privileges (each on different tables)
> 100 privileges ~2 RPCs/sec
> 1000 privileges ~1.5 RPCs/sec
> 2000 privileges - ~.5 RPCs/sec
> 4000 privileges - ~.2 RPCs/sec
> Configuration:
> - Sentry Policy Service -> Postgres Backend DB
> {code}
> This means the time to actually execute one grant/revoke RPC using a policy that is securing
4000 tables is >5s.
> I tried scaling up the number of clients, but that doesn't appear to improve the throughput
since there is a lot of locking that is happening inside the Sentry Policy Service.

This message was sent by Atlassian JIRA

View raw message