> For the complete documentation index, see [llms.txt](https://docs.nfh.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nfh.global/product-documentation/products/registr/benchmark.md). # Registry service benchmark This page summarizes a set of performance tests conducted on the Registry Service in December 2025 to understand how it behaves under different data sizes and… This page summarizes a set of performance tests conducted on the Registry Service in December 2025 to understand how it behaves under different data sizes and infrastructure configurations. **The goal is to give operators a practical sense of the throughput and latency they can expect under different data sizes and load levels.** The results below are based on sustained load tests using the open-source **k6** tool and reflect steady-state behavior rather than short-lived spikes. *** ## ✨ At a Glance |

πŸš€ \~2,200

requests/sec

Peak throughput

|

⚑ \~42 ms

p95 latency

At peak throughput

|

πŸ“ˆ \~2x

throughput gain

2 vCPU β†’ 4 vCPU

| | :---------------------------------------------------------------------: | :----------------------------------------------------------------------: | :---------------------------------------------------------------------: | *** ## πŸ”¬ Test Methodology Benchmarks were run under controlled conditions using **k6** virtual users against a live Registry Service instance. #### Traffic Simulation | Parameter | Value | | -------------------- | -------------------------- | | **Concurrent Users** | 50–100 virtual users | | **Duration** | 10 minutes (R0: 2 minutes) | #### Infrastructure Configurations Tested | Config | Memory | vCPU | | ------ | :----: | :--: | | Small | 4 GB | 2 | | Medium | 8 GB | 2 | | Large | 16 GB | 4 | #### Dataset Shapes Tested | Namespaces | Registries / Namespace | Records / Registry | Total Records | | :--------: | :--------------------: | :----------------: | :-----------: | | 500 | 1 | 200 | 100,000 | | 2,000 | 2 | 100 | 400,000 | | 2,000 | 2 | 200 | 800,000 | | 3,000 | 2 | 250 | 1,500,000 | | 1,500 | 2 | 500 | 1,500,000 | All reported values represent **steady-state performance**. *** ## πŸ“ˆ Run Results {% hint style="info" %} **Reading the latency columns**\ p90 = 90% of requests completed within that time. p95 captures the 95th percentile β€” the experience of nearly all requests, including slower ones. {% endhint %} | # | Thread Count | Namespaces | Registries / Namespace | Records / Registry | Total Records | Duration | Memory | CPU | Iterations | TPS | Avg (ms) | Min (ms) | Med (ms) | Max (ms) | p90 (ms) | p95 (ms) | | :-: | :----------: | :--------: | :--------------------: | :----------------: | :-----------: | :------: | :----: | :-: | :--------: | :-----: | :------: | :------: | :------: | :------: | :------: | :------: | | R0 | 50 | 500 | 1 | 200 | 100,000 | 2m | 4GB | 2 | 123,938 | 1032.34 | 48.18 | 0.31 | 46.83 | 286.86 | 70.71 | 78.63 | | R1 | 50 | 500 | 1 | 200 | 100,000 | 10m | 4GB | 2 | 656,173 | 1093.53 | 45.5 | 0.32 | 44.56 | 284.97 | 66.21 | 72.92 | | R2 | 50 | 500 | 1 | 200 | 100,000 | 10m | 8GB | 2 | 696,003 | 1159.94 | 42.88 | 0.29 | 42.27 | 175.11 | 61.88 | 67.86 | | R3 | 100 | 500 | 1 | 200 | 100,000 | 10m | 8GB | 2 | 693,374 | 1155.47 | 86.31 | 0.3 | 85.21 | 523.17 | 118.7 | 129.11 | | R4 | 50 | 2,000 | 2 | 100 | 400,000 | 10m | 8GB | 2 | 1,228,847 | 2048.01 | 24.17 | 0.27 | 23.22 | 317.04 | 36.45 | 40.82 | | R5 | 50 | 2,000 | 2 | 200 | 800,000 | 10m | 8GB | 2 | 676,575 | 1127.54 | 44.08 | 0.3 | 42.83 | 1035.82 | 63.83 | 70.69 | | R6 | 50 | 2,000 | 2 | 200 | 800,000 | 10m | 16GB | 4 | 1,337,820 | 2229.62 | 22.17 | 0.27 | 20.84 | 134.52 | 36.38 | 41.82 | | R7 | 50 | 3,000 | 2 | 250 | 1,500,000 | 10m | 16GB | 4 | 1,070,116 | 1783.44 | 27.78 | 0.28 | 26.56 | 208.58 | 43.78 | 49.46 | | R8 | 50 | 1,500 | 2 | 500 | 1,500,000 | 10m | 16GB | 4 | 575,289 | 958.75 | 51.89 | 0.25 | 46.45 | 301.22 | 87.21 | 103.98 | *** ## πŸ” Key Findings {% tabs %} {% tab title="⚑ Infra Scaling" %} Scaling from 2 to 4 vCPUs on an 800K-record dataset nearly **doubled throughput** while cutting tail latency by over **85%**. | Metric | 8 GB / 2 vCPU | 16 GB / 4 vCPU | Improvement | | ------------ | ------------: | -------------: | :---------------: | | Throughput | 1,127 TPS | 2,229 TPS | **\~2x** πŸš€ | | p95 Latency | 70.7 ms | 41.8 ms | **41% faster** πŸš€ | | Max Latency | 1,035 ms | 134 ms | **87% faster** πŸš€ | | {% endtab %} | | | | {% tab title="πŸ“¦ Dataset Scale" %} With well-distributed data, the Registry Service handles **1.5 million records** efficiently on a 16 GB / 4 vCPU instance β€” sustaining **\~1,800 TPS** with **p95 under 50 ms**. | Records | Namespaces | TPS | p95 Latency | | :-------: | :--------: | ----: | ----------: | | 100,000 | 500 | 1,159 | 67.9 ms | | 800,000 | 2,000 | 2,229 | 41.8 ms | | 1,500,000 | 3,000 | 1,783 | 49.5 ms | The service scales gracefully across dataset sizes β€” even at 15Γ— the baseline record count, throughput stays above **1,700 TPS**. {% endtab %} {% endtabs %} *** ### 🎯 Key Takeaways {% hint style="success" %} * **Highly Scalable:** Throughput nearly doubles when scaling from 2 to 4 vCPUs β€” consistent, predictable gains with additional compute. * **Low Latency at Scale:** Even at 800K records, the service sustains \~2,200 TPS with p95 latency of just \~42 ms on a 16 GB / 4 vCPU instance. * **Stable Under Sustained Load:** No latency degradation observed over 10-minute test runs, demonstrating robust steady-state behavior. * **Handles Large Datasets:** With well-distributed data, the service sustains \~1,800 TPS even at 1.5 million records. {% endhint %} *** ## Final note These results highlight the Registry Service's ability to deliver **consistent, predictable performance under sustained load** across a wide range of dataset sizes and configurations. The service demonstrates clear scaling behavior, improving both throughput and latency as additional CPU and memory are made available. While real-world performance will naturally vary based on data layout and usage patterns, the observed results show that the Registry Service can comfortably **support high-throughput, low-latency workloads** when appropriately sized. Overall, the tests reinforce that the Registry Service is **well-suited for production workloads**, with performance characteristics that scale in a transparent and predictable way. Benchmarking data collected using k6 against the NFH fabric Registry Service in December 2025. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.nfh.global/product-documentation/products/registr/benchmark.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.