Hi, I’m currently preparing performance and load t...
# permit-saas
m
Hi, I’m currently preparing performance and load tests for endpoints such as
/check
,
/bulk_check
,
/user-permissions
, and
/authorized-users
. I’d like to ask if you have conducted any internal performance or scalability tests for the PDP and related APIs — and if so, could you share any benchmark results or performance assumptions (e.g., expected throughput, latency, or concurrency levels)? I understand that the actual performance depends heavily on where the PDP is hosted (cloud vs. on-prem, region, hardware specs), but any reference numbers or best practices would be very helpful for setting up my own test plan.
a
Hi @Michał Wójcik, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.
Based on the available documentation, here are the performance benchmarks and recommendations for PDP performance testing: Performance Benchmarks Salt Security achieved sub-20ms latency while handling thousands of authorization requests per second by running local PDPs within their infrastructure (1) . They extensively tested and measured performance, achieving sub-millisecond response times even under high load . With proper optimizations, you can expect several thousand RPS with less than 10ms latency per request (2) . System Requirements For starting values: • ​*CPU*​: ~200 mcores with upper limit of at least ~1000 mcores to enable short CPU spikes • ​*Memory*​: ~512Mb as a baseline For memory scaling, use the formula: ​*# of policy objects X 6kb*​ (where policy objects include users, resource instances & tenants) . For example, an environment with 100k users, 500k resource instances and 100 tenants would need ~3.5Gb of memory . Performance Optimization Tips To achieve high throughput and low latency : • Deploy the PDP in the same VPC as your application to minimize network latency • Disable decision debug information in production by adding
--env PDP_DEBUG=False
• Optimize base policy for your specific use case (disabling unused features like ReBAC checks can speed up execution) Caching Configuration The PDP includes a configurable caching mechanism that significantly improves performance by reducing redundant policy evaluations (3) . The cache supports: •
/allowed
•
/allowed/bulk
•
/user-permissions
•
/authorized_users
You can configure the cache to use either in-memory storage for single instances or Redis for distributed caching across multiple PDP instances . Scaling Strategies For horizontal scaling (2) : • Deploy multiple PDP instances behind a load balancer when CPU becomes a bottleneck • For multi-tenant environments, use tenant-based sharding for data/memory scaling
To learn more, see the sources I considered: [[1] Salt Security: Enterprise-Grade API Security with Fine-Grained Authorization](https://www.permit.io/blog/salt-security-enterprise-grade-api-security-with-fine-grained-authorization) [[2] Deploy Permit to Production](https://docs.permit.io/how-to/deploy/deploy-to-production) [[3] Permit's PDP (Policy Decision Point)](https://docs.permit.io/concepts/pdp/overview)
o
Hey @Michał Wójcik As you mentioned, the performance heavily relies on the infrastructure the PDP is hosted on, but also on the actual policy & data it holds and the query itself. e.g, querying
/user-permissions
on a user with 1 permission and on a user with 10k permissions via a heavily deep or wide relationship graph will have completely different results. The same example goes for all the queries you mentioned. If you encounter any performance issues during your performance & load tests, we’d be happy to help you configure your setup/policy for the best performance. Notice that the PDP is highly dependent on CPU but also on Memory depending on the data volume
✅ 1