ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Madhan Neethiraj (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (RANGER-1827) micro benchmark for policy evaluation
Date Wed, 11 Oct 2017 21:22:00 GMT

    [ https://issues.apache.org/jira/browse/RANGER-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16200984#comment-16200984
] 

Madhan Neethiraj edited comment on RANGER-1827 at 10/11/17 9:21 PM:
--------------------------------------------------------------------

[~andrewsmith87] - updates to perf tool is pretty cool! It makes it easier to understand Ranger
policy engine performance, Please consider the following:
- it will be helpful to cover additional policy-counts: 5, 50, 100, 250, 500, 1000, 2000,
3000, 4000, 5000
- it will be helpful to cover additional concurrent-counts: 1, 5, 10, 20, 30, 40, 50, 100
- 90% of the policies are created with random-named resources that will not be accessed (i.e
in access-requests); remaining 10% policies are created with same set of resources (i.e. all
known resources). I would suggest the following:
-- this 90-10 should become more like 30-70
-- policies should not include same set of resources. They should be randomized. For example:
{ database=[database_1, database_5], table=[table_3, table_27, table_63, table_90], column=[column_7,
column_31, column_23, column_67, column_113, column_239, column_851}
- access requests include "\*" for database/table/column. This is won't be a normal use-case.
Instead, I would suggest to pick a random value (from KNOWN_*) for each resource
- use of NEVER_ALLOWED_ACCESS_TYPES may not be helpful - as this is unlikely to be encountered
often




was (Author: madhan.neethiraj):
[~andrewsmith87] - updates to perf tool is pretty cool! It makes it easier to understand Ranger
policy engine performance, Please consider the following:
- it will be helpful to cover additional policy-counts: 5, 50, 100, 250, 500, 1000, 2000,
3000, 4000, 5000
- it will be helpful to cover additional concurrent-counts: 1, 5, 10, 20, 30, 40, 50, 100
- 90% of the policies are created with random-named resources that will not be accessed (i.e
in access-requests); remaining 10% policies are created with same set of resources (i.e. all
known resources). I would suggest the following:
-- this 90-10 should become more like 30-70
-- policies should not include same set of resources. They should be randomized. For example:
{ database=[database_1, database_5], table=[table_3, table_27, table_63, table_90], column=[column_7,
column_31, column_23, column_67, column_113, column_239, column_851}
- access requests include "*" for database/table/column. This is won't be a normal use-case.
Instead, I would suggest to pick a random value (from KNOWN_*) for each resource
- use of NEVER_ALLOWED_ACCESS_TYPES may not be helpful - as this is unlikely to be encountered
often



> micro benchmark for policy evaluation
> -------------------------------------
>
>                 Key: RANGER-1827
>                 URL: https://issues.apache.org/jira/browse/RANGER-1827
>             Project: Ranger
>          Issue Type: Test
>          Components: Ranger
>    Affects Versions: master
>            Reporter: Endre Kovacs
>            Assignee: Endre Kovacs
>            Priority: Minor
>              Labels: performance, test
>             Fix For: 1.0.0
>
>         Attachments: 0001-RANGER-1827-microbenchmark-for-RangerPolicyEngine.patch, policy-evaluation-performance.png
>
>
> implement micro benchmark testing the performance of RangerPolicyEngine at different
load of # of policies and # of concurrent users



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message