https://linen.dev logo
Join Slack
Powered by
When I use PDP, I see a log line: `2026-03-27T08:4...
# permit-saas
b
When I use PDP, I see a log line: 
2026-03-27T08:47:23.988300+0000 | horizon.pdp | INFO | Removing callback '<http://localhost:8181/v1/data/permit/rebac/cache_rebuild>' from the register
Does disabling the cache make PDP slower, and how can I enable it again?
a
Hi @B22DCCN393 Nguyễn Việt Huy, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.
The log line you're seeing about removing the 
cache_rebuild
callback is normal PDP behavior and doesn't necessarily mean your cache is disabled. (1) The PDP includes a configurable caching mechanism that significantly improves performance by reducing redundant policy evaluations. (2) When enabled, the cache stores results of policy decisions with a configurable time-to-live (TTL) . ​*To configure the PDP cache*​, use these environment variables: (3) ​*`PDP_CACHE_STORE`*​ - The cache storage type. Options include: 
none
, 
in-memory
, and 
redis
. Default is 
none
. ​*`PDP_CACHE_TTL`*​ - Time-to-live in seconds for cached items. Default is 
3600
. ​*`PDP_CACHE_MEMORY_CAPACITY`*​ - Memory capacity in MiB for in-memory cache (when using in-memory store) . Default is 
128
. ​*`PDP_CACHE_REDIS_URL`*​ - Redis connection URL (when using redis store) . Default is "" (empty string) . ​*To enable caching*​, set the 
PDP_CACHE_STORE
environment variable to either 
in-memory
or `redis`:
Copy code
PDP_CACHE_STORE=in-memory
Or for Redis-based caching:
Copy code
PDP_CACHE_STORE=redis
PDP_CACHE_REDIS_URL=<redis://your-redis-host:6379>
Yes, disabling the cache can make the PDP slower, as caching significantly improves performance for frequently evaluated permissions. (2) The cache is supported for 
/allowed
, 
/allowed/bulk
, 
/user-permissions
, and 
/authorized_users
endpoints. To help investigate further, could you share: 1. Which Workspace / Project / Env you are using 2. What calls you are performing (as SDK code or CURL) 3. Which PDP version you are running 4. Relevant logs from your PDP
To learn more, see the sources I considered: [[1] Unable to push the policy data since OPA is not ready yet in sidecar pattern](https://github.com/permitio/PDP/issues/266) [[2] Permit's PDP (Policy Decision Point)](https://docs.permit.io/concepts/pdp/overview) [[3] Configurations](https://docs.permit.io/concepts/pdp/configuration)
Appreciate the feedback! Feel free to ask me again with additional guidance or context.
😮‍💨 1
b
PDP actually returns results very quickly, in under 20 ms. But for some reason, when I call the 
/allowed
endpoint again after some time, the latency goes up to around 300 ms. I don’t understand what happened
image.png,image.png
d
Hi @B22DCCN393 Nguyễn Việt Huy, if you can provide some additional context that would be helpful. 1. Which workspace, project, env are you working in? 2. What is your complete request/response? 3. Can you share relevant logs from your PDP? Specifically, Logs around the time of the 650ms request
b
projId: 62a17c26e83141b78874bed53abb9b6f envId: f3404f333de34fc8a68542591608bc5c Request http://localhost:7766/allowed { "user": { "key": "test" }, "action": "delete", "resource": { "type": "document", "key": "123", "tenant": "default", "context": { "tenant": "default" } }, "context": {} } I’m creating an inheritance rule where 
department#thanh_vien
(
thanh_vien
= member in English) inherits from 
document#thu_ky
(
thu_ky
= secretary in English). After setting up the inheritance rule, I repeatedly changed the policy of a document and tested it with 
/allowed
. The result was that the first request after a policy change took longer to evaluate, and it only became fast from the second request onward
I just want to know whether 
rebac/cache_rebuild
is causing this issue, because I previously saw that 
rebac/cache_rebuild
was still present in older PDP versions
The first-request slowness still happens similarly when I try changing the relation between 
department
and 
document
again
o
When you change the policy/data you invalidate the cache - so of course the first request (without a cache) would be slower than subsequent cached results.
Re:
endpoint again after some time, the latency goes up to around 300 ms
That’s (probably) just cache TTL expiring. I’m not really sure what is the issue you’re trying to solve; is seems your PDP and its cache are performing well . Once in a while cache invalidation is a normal behavior
👍 1
b
Is there a way to cache data immediately when it changes?
As an engineer, I always pay attention to the smallest details, and I don't think this is an issue that should be overlooked. What I'm really wondering is, when dealing with larger relational datasets, is caching periodically after each change more important than recalculating the cache on the first request, and are there any options for this?
o
The cache is on the result of the query, not the data itself (Paying attention to smallest details? How about the big details? 😅) You can trigger the query/queries following a change using the callback feature or your own event-driven architecture on triggering the change itself.
You'd of course consider that there are many potential queries you can run, and running all of them in advance would be very costly
you'd need some heuristic or plan to decide which queries to run and when.
b
So you mean just caching the query results, right? I don't think so, because on a data tree with inheritance, you're actually checking inheritance relationships by repeatedly calculating inheritance rules just to cache the results? A project might have an inheritance tree with a depth of 20-30, so caching the results isn't enough to cover the computational cost. Finally, I want to ask: when the data changes (adding, modifying, deleting the tree, removing permissions, assigning permissions), caching might work with the results (as you said), but on a large dataset, querying the tree is a costly operation.
o
That’s literally what I explained. I’m starting to think you’re trolling
😮‍💨 1
Sir this is a serious community for engineers working on real problems in the permissions space, I ask that you respect our community guidelines
b
If you find my question bothersome, then I won't ask any more
3 Views
Open in Slack
PreviousNext
Powered by