Add Cloud PDP benchmarks documentation#624
Conversation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
✅ Deploy Preview for permitio-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Pull request overview
Adds a new documentation page describing Cloud PDP performance benchmarks and links it from the PDP section in the docs sidebar.
Changes:
- Added a new Cloud PDP Benchmarks MDX page with RBAC/ReBAC latency and throughput tables.
- Linked the new page under The Policy Decision Point (PDP) in the docs sidebar.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
sidebars.js |
Adds the new Cloud PDP benchmarks doc to the PDP sidebar section. |
docs/concepts/pdp/cloud-pdp-benchmarks.mdx |
Introduces benchmark results and key takeaways for Cloud PDP performance. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| ## Key Takeaways | ||
|
|
||
| - **Sub-15 ms average latency** across all policy models at the P50 level, even under concurrent load. |
|
|
||
| - **Sub-15 ms average latency** across all policy models at the P50 level, even under concurrent load. | ||
| - **Throughput scales linearly** — 10 concurrent requests yield ~10x throughput with minimal latency increase. | ||
| - **ReBAC depth has modest impact** — adding relationship depth (1 → 3 hops) increases average latency by only ~3 ms under the same concurrency. |
| All tests were run against a production Cloud PDP endpoint over a **10-minute window** per scenario. Latencies are round-trip times (request → response) over HTTPS. | ||
|
|
zeevmoney
left a comment
There was a problem hiding this comment.
This is an automated review. See comments.
|
|
||
| ## Key Takeaways | ||
|
|
||
| - **Sub-15 ms average latency** across all policy models at the P50 level, even under concurrent load. |
There was a problem hiding this comment.
Statistic mislabeled — "average latency" and "P50" are conflated
This takeaway reads "Sub-15 ms average latency ... at the P50 level", but average (mean) and P50 (median) are two different statistics. The reader can't tell which one the "Sub-15 ms" claim refers to. Both happen to be true against the tables (P50 Avg ranges 6.43–12.0 ms; Average-latency Avg ranges 7.80–14.5 ms), so pick one and state it cleanly.
Suggestion: Reword to a single statistic, e.g. "P50 latency stays under 15 ms across all policy models, even under concurrent load" (or "average latency under 15 ms ...").
(Copilot raised this on this line and it is still unresolved/unaddressed.)
| ## Key Takeaways | ||
|
|
||
| - **Sub-15 ms average latency** across all policy models at the P50 level, even under concurrent load. | ||
| - **Throughput scales linearly** — 10 concurrent requests yield ~10x throughput with minimal latency increase. |
There was a problem hiding this comment.
"Throughput scales linearly" overclaims from two data points
The data has only two concurrency levels (1 and 10), so "scales linearly" is stronger than the measurements support — two points can't establish linearity, and the relationship isn't even exactly 10x (RBAC: 5.80 → 56.5 req/s ≈ 9.7x; ReBAC depth-1: 5.43 → 54.7 ≈ 10.1x). Soften to the observed claim.
Suggestion: "Throughput scales near-linearly with concurrency — 10 concurrent requests yield roughly 10x throughput with minimal latency increase."
(Copilot raised this on this line and it is still unresolved/unaddressed.)
|
|
||
| This page presents performance benchmarks for the **Cloud PDP**, measured across different policy models, concurrency levels, and relationship depths. | ||
|
|
||
| All tests were run against a production Cloud PDP endpoint over a **10-minute window** per scenario. Latencies are round-trip times (request → response) over HTTPS. |
There was a problem hiding this comment.
Benchmark methodology underspecified
For readers to interpret these numbers, the intro should state the measurement conditions: the date/period the run was taken, the Cloud PDP region and the client (load-generator) region/proximity, which endpoint(s) were exercised (e.g. POST /allow), the request/payload shape, and the policy size (number of roles/resources/relationship tuples). Without these, "5.80 req/s at single concurrency" is hard to reconcile (a single-client closed-loop run is throughput = 1 / latency, which the 8.17 ms avg ≈ 5.8 req/s confirms — worth stating explicitly so it doesn't read as a throughput ceiling).
Suggestion: Add a short "Methodology" paragraph under the intro listing date, regions, endpoint, payload, policy size, and load model (closed-loop vs open-loop).
(Copilot raised this on the intro line and it is still unresolved/unaddressed.)
Summary
Test plan
🤖 Generated with Claude Code