Hey folks, we're trying to understand if the laten...
# permit-saas
j
Hey folks, we're trying to understand if the latency we're seeing when using the PDP proxy for facts is within the expected range. We're seeing requests to create role_assignments or relationship_tuples taking anywhere from 8 to 14 seconds. The PDP has a lot of headroom resource wise so we're wondering what else to try. We've also seen what seems like quite high latency on the GET endpoints for these, even when filtered to 1 object, without the proxy, can take 4+ seconds.
a
Hi @James Dalton, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.
The latency you're experiencing (8-14 seconds for POST operations, 4+ seconds for GET operations) is significantly higher than expected. When using proxy facts via PDP, API requests wait until data is fully synced to the PDP before returning, which does increase latency compared to direct Permit API calls (1) . However, the documentation indicates that "despite increased request latency, data updates are typically received faster compared to data updates via the Permit API" . ​*Configuration to Check:*​ The default timeout for proxy facts is controlled by
PDP_LOCAL_FACTS_WAIT_TIMEOUT
, which defaults to
10
seconds (2) . Your 8-14 second latency suggests requests might be approaching or hitting this timeout. You can adjust this via:
Copy code
PDP_LOCAL_FACTS_WAIT_TIMEOUT=<seconds>
The
PDP_LOCAL_FACTS_TIMEOUT_POLICY
determines behavior when timeout occurs - it defaults to
ignore
(respond immediately) but can be set to
fail
(return 424 status) . ​*Performance Considerations:*​ The documentation notes several factors that can impact performance when using proxy facts (1) : • ​*Increased API Latency*​: Expected due to waiting for synchronization • ​*CPU Usage*​: PDP CPU usage may increase with high traffic to proxy facts endpoints • ​*Unsupported APIs*​: APIs not explicitly supported are still routed through the PDP to the Permit API, which can result in higher latency ​*Deployment Architecture:*​ The feature works best when PDPs are deployed as a Centralized PDP or PDP Sidecar to your application, ensuring the same PDP instance handles both data creation and permission checks . Using a PDP Cluster with load balancing is "less optimal" because permission checks may be routed to PDPs that haven't received the data update yet . To help investigate further, could you provide: 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] Send Consistent Updates (Read-Your-Own-Writes)](https://docs.permit.io/how-to/manage-data/local-facts-uploader) [[2] Configurations](https://docs.permit.io/concepts/pdp/configuration)
j
Workspace: Risksmart App, Project ID: 2ff17b7b36e84a1cb0f4d21d4c623b64 Env ID: b33b28b93c174a7193e27583fb397326 PDP version: 0.9.9 Setup - Centralised PDP on fargate with 4 cores, 8 GB of RAM.
Right now we're looking at 92% of our request processing time being spent interacting with permit on creates / updates / deletes. With our front end still being synchronous for the foreseeable future we could really do with some improvement in these numbers.
d
Hey @James Dalton, Can you send over (1) Relevant PDP Logs (2) Where you are calling the GET operations
z
@James Dalton I’ve opened a DM with the relevant team members, please send it there.