BTW, I did my test using the old mod-authtoken, and also tried hitting mod-perms API directly. You can try that and see the difference.

I ran the check-out / check-in process in MODAT-51.. I did not see any noticable difference between master of mod-permissions and . This is because the caching is done in mod-authtoken anyway and that kicks in first.

Attached are check-in/check-out for folio-testing using patch.. The i-set is the initial check-in/check-out which are a lower slower then subsequent requests.

The set for master version of mod-permissions (without ) are attached in MODAT-51

The existing cache we put in was to improve this API. It returns an array of string. https://s3.amazonaws.com/foliodocs/api/mod-permissions/permissions.html#perms_users__id__permissions_get

The above logged line uses this API and it expands module perm set to a full blown permission object with all the extra fields. https://s3.amazonaws.com/foliodocs/api/mod-permissions/permissions.html#perms_permissions__id__get

I do not have the exact metrics for what you are asking. I was simply trying to change the existing cache (select jsonb->>'permissionName', jsonb->>'subPermissions') to (select all). The db query is fast (under ms), but retrieve all the data (1160 rows) from db and convert to full Permission object takes time. From OKAPI log, it is over 1 second. If we refresh cache as frequent as before (30 seconds), it is not sustainable.

can you clarify the statement above, I am not sure I understand.

Also, can you provide metrics for:

• loading permission into the cached (DB query time), e.g for BugFest-size permission table

• expanding permissions (CPU time)

By inspecting the API response it looks like the full permission objects are returned. Current cache based expansion only helps perm to subperm names.