yuqi1129 commented on issue #11781:
URL: https://github.com/apache/gravitino/issues/11781#issuecomment-4809049548
Thanks for the benchmark. Before I start to optimize, I read the JCasbin
code first. From the code, the result may be the opposite of what we think. A
few things to check with real data:
1. group→role is not an extra step per request.
The code loads roles with one SQL query (batchGetAuthSubjectsForUser). This
one query gets the user, its groups, its direct roles, and its group roles
together — only one DB call. The result is also cached in groupRoleCache. So
the two ideas in the issue ("cache group→role" and "batch the user→group→role
chain") are mostly already done.
2. There is no group inside the enforcer.
Group roles are bound to the user with the same bindUserRoles(userId,
roleId) as direct roles. So in JCasbin, every row is userId → roleId, no matter
if the role comes from a user or a group.
With this test setup (User Auth = 2 roles per user role_all + roleN; Group
Auth = 1 shared role role_all), Group Auth has fewer roles per user. So the
check should be equal or even a little faster, not 2–3× slower.
So from the code, the extra latency is probably not from the JCasbin check.
More likely places:
- The benchmark may use an old version, before the prefetch + groupRoleCache
were added.
- The login part: Basic auth runs selectIdpUserWithGroups (a JOIN on
idp_user_group_rel) on every request. In Group Auth every user has group rows
to join. If this table has no index, this query gets slow — but this is login
cost, not authorization.
Next step: I will test on a real dataset and add timing for each part (login
vs. the prefetch SQL vs. enforcer.enforce), to find where the ~130–170ms really
goes, instead of adding another group→role cache that already exists. I will
share the numbers later.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
