{"title":"Performance","description":"Amber V2 benchmark results, methodology, limits, and reproduction evidence","section":"guides","version":"v2","path":"guides/performance","canonical_url":"https://amberframework.org/docs/v2/guides/performance","markdown_url":"https://amberframework.org/docs/v2/guides/performance.md","inherited":false,"content_markdown":"# Performance\n\nAmber treats performance as an architectural property and a documentation\nobligation. Every published number should travel with its workload, hardware,\nprotocol, duration, errors, and limits.\n\n## Hosted Amber V2 result\n\nOn July 17, 2026, the Amber V2 performance lab measured a mature mixed\napplication on a DigitalOcean Basic one-vCPU, 512 MB-class target. A separate\nfour-vCPU host generated load over a private VPC.\n\n| Current Amber JSON path | Result |\n|---|---:|\n| Median throughput | **21,795 requests/second** |\n| Median p50 latency | 655 microseconds |\n| Median p99 latency | 4.20 milliseconds |\n| Repetitions | 7 |\n| Socket errors | 0 |\n| Non-2xx responses | 0 |\n\nThis result is whole HTTP traffic over real sockets. It is not an in-process\nrouter lookup rate.\n\n## This website on the same smallest target\n\nOn August 11, 2026, we compiled the Amber Framework website release candidate\nfor Linux `x86_64-v2` and ran it on the current $4/month DigitalOcean size: one\nshared vCPU with 512 MB advertised memory. A separate four-vCPU machine drove\ntraffic over the private VPC.\n\n| Actual website path | Median throughput | Median-trial p50 | Median-trial p99 |\n|---|---:|---:|---:|\n| Complete 26,271-byte homepage | **5,907 req/s** | 2.67 ms | 7.07 ms |\n| Rendered `/index.json` | **9,355 req/s** | 1.66 ms | 5.84 ms |\n| Static `/llms.txt` | **14,085 req/s** | 1.08 ms | 3.90 ms |\n\nEach row used four load-generator threads, 16 persistent connections, a\nfive-second warmup, and five 15-second trials. Together, these baseline and\nWebSocket-concurrency stages delivered 2,944,287 successful HTTP responses\nwith zero reported socket errors and zero non-2xx responses.\n\nThe same release candidate then held 100, 500, and 1,000 joined WebSocket\nclients. All 2,600 connection attempts across the stages and the second\n1,000-client cycle succeeded. During the first 1,000-client hold, the rendered\nJSON path sustained a median **8,058 requests/second**; the median trial's p99\nwas 26.77 ms.\n\nThis is useful capacity evidence, but not a scaling curve. The connection\nstages ran sequentially on a shared-vCPU target and were visibly noisy: the\n500-client stage was slower than the 1,000-client stage. Clients joined a topic\nand then remained idle, so the result does not measure broadcast fan-out, slow\nconsumers, TLS, a reverse proxy, a public network, or multiple Amber processes.\n\nThe complete [website and WebSocket evidence](/benchmarks/amber-v2-site-websocket-2026-08-11.json)\nincludes every throughput trial, response size, resource snapshot, executable\nfingerprint, method, and limitation.\n\n## Executable schema-contract result\n\nOn August 13, 2026, we measured the request and response schema implementation\nthat shipped in Amber `2.0.0-beta.5`. The benchmark ran the reviewed release\ncommit before the public tag was created; the tag points to that same commit.\n\nThe target was the exact DigitalOcean `s-1vcpu-512mb-10gb` size: one shared\nvCPU, 512 MB advertised memory, a 10 GB disk, and $4/month at test time. A\nseparate four-dedicated-vCPU machine generated load over an isolated private\nVPC. Each result below is a complete HTTP response over a real socket—not a\nrouter lookup.\n\n| Complete HTTP scenario | Median throughput | Observed range | Median p50 | Median p99 |\n|---|---:|---:|---:|---:|\n| Generic JSON decode without schemas | 20,728 req/s | 19,019–22,618 | 0.688 ms | 2.813 ms |\n| Request and response validated as JSON | **19,488 req/s** | 18,573–22,236 | 0.721 ms | 3.185 ms |\n| Request and response validated as CBOR | **21,742 req/s** | 19,904–23,256 | 0.646 ms | 2.921 ms |\n| Authenticated COSE request and response | **14,443 req/s** | 10,962–15,160 | 1.006 ms | 3.612 ms |\n\nThe request had eight fields and the acknowledgement had five. Compared with\ngeneric JSON decoding, enforcing both schemas cost 6.0% in this workload.\nValidated CBOR was 11.6% faster than validated JSON and reduced the request\nbody from 257 bytes to 223 bytes. Bidirectional COSE authenticated and decrypted\nthe request, validated it, then encoded, authenticated, and encrypted the\nresponse with a fresh nonce; it was 25.9% slower than validated JSON.\n\nAll **7,974,608** measured requests returned HTTP 200. The 28 retained runs had\na 100% success rate and no unexpected error categories. The Amber process\npeaked at 16.6 MiB on the 512 MB target.\n\nThe previous round used the same plans, region, reported processor models,\n1,002-route workload, payloads, load tool, 16 connections, rotating order, and\nseven 15-second measurements per scenario. After the integrated router,\nrequest, params, pipeline, and responder work, median throughput changed as\nfollows:\n\n| Scenario | Previous round | Amber 2.0.0-beta.5 | Change |\n|---|---:|---:|---:|\n| Generic JSON | 13,889 req/s | 20,728 req/s | +49.2% |\n| Validated JSON | 12,987 req/s | 19,488 req/s | +50.1% |\n| Validated CBOR | 14,886 req/s | 21,742 req/s | +46.1% |\n| Bidirectional COSE | 10,381 req/s | 14,443 req/s | +39.1% |\n\nThat before-and-after covers the complete integrated performance patch, not\nthe router alone. The rounds also used separate short-lived cloud machines, so\nnormal cloud-host variation cannot be eliminated.\n\nThe endpoint is a synthetic in-memory acknowledgement. It includes HTTP\nparsing and serialization, route dispatch through 1,002 routes, body decoding\nor decryption, schema validation, controller execution, response validation,\nand response encoding or encryption. It excludes a database, external\nservices, TLS termination, HTML rendering, logging middleware, and the public\ninternet. Keep the public-site result near 5,900 req/s separate from this\nframework-contract workload.\n\nRead [the human explanation](/blog/2026/08/13/amber-v2-executable-schema-contracts),\nthen inspect the [machine-readable summary](/benchmarks/amber-v2-schema-contract-round27-summary.json)\nwhen you need exact source values.\n\n## Workload\n\nThe release-mode `x86_64-v2` binary installed 1,000 routes and replayed the same\ndeterministic 4,096-request table in every trial:\n\n| Dimension | Mix |\n|---|---|\n| Route shapes | 45% static, 25% REST ID, 15% ID plus action, 5% nested, 5% constrained, 5% glob |\n| HTTP methods | 65% GET, 20% POST, 8% PUT, 5% PATCH, 2% DELETE |\n| Locality | 70% selected the first 20% in each method-and-shape cell |\n| Query strings | 20% of requests |\n| Connections | 16 |\n| Load-generator threads | 4 |\n| Warmup | 5 seconds |\n| Measurement | 15 seconds |\n| Repetitions | 7, with rotating variant order |\n\nWrites carried an eight-field JSON CRUD/mobile payload. Controllers consumed\nevery decoded field and serialized an acknowledgement. Reads consumed captured\nroute parameters and serialized a response. The measured path included the\nCrystal HTTP parser and serializer, Amber routing and pipeline dispatch, body\ndecoding, controller work, and JSON serialization.\n\nAcross the complete seven-variant body-codec/compiler matrix, the load\ngenerator received **18,728,053 successful responses** with zero socket errors\nand zero non-2xx responses.\n\n## What the number means\n\nThe 21,795 requests/second result is more demanding and more representative\nthan a static-response endpoint. It supports the narrower statement that Amber\nV2 can exceed 10,000 requests/second in this documented one-vCPU hosted\nworkload.\n\nIt does not establish:\n\n- a cross-framework ranking;\n- a universal result for every Amber application;\n- a production capacity plan or service-level agreement;\n- database, cache, proxy, TLS, or public-internet performance;\n- the throughput of the final beta tag on different hardware.\n\nApplication behavior, infrastructure, compiler version, connection strategy,\nand request shape can move the result substantially. Benchmark your deployed\npath before making capacity decisions.\n\n## Router microbenchmarks are separate\n\nAmber also measures route matching in isolation. Those results can reach\nmillions of lookups per second because they intentionally exclude sockets,\nHTTP parsing, middleware, controller dispatch, template rendering, and response\nserialization. They are useful for choosing router implementations, but they\nmust never be presented as HTTP requests per second.\n\n## Released router before and after on the $4 target\n\nOn August 13, 2026, we ran a corrected router-only comparison on the exact\nDigitalOcean `s-1vcpu-512mb-10gb` size: one shared vCPU, 512 MiB advertised\nmemory, 469,236 KiB visible memory, and no swap. Both static binaries used\nCrystal 1.21.0 and the same workload. The comparison was `amber_router` 0.4.4\nagainst Amber `2.0.0-beta.4`.\n\nEach of 12 scenarios used seven paired trials with alternating order. Amber V2\nwas faster in all 84 individual pairs, and every scenario's median bootstrap\ninterval excluded `1.0x`. The geometric mean across the 12 scenario medians\nwas **1.89x**.\n\n> **Unit:** every rate in this table is an in-process router lookup per second,\n> not a completed HTTP request per second.\n\n| Route table | Lookup | V1 router lookups/s | V2 beta.4 router lookups/s | Median paired speedup |\n|---:|---|---:|---:|---:|\n| 100 | Fixed | 599,440/s | 885,523/s | **1.44x** |\n| 100 | Variable | 796,564/s | 1,205,931/s | **1.55x** |\n| 100 | Glob | 384,426/s | 608,145/s | **1.58x** |\n| 100 | Not found | 669,406/s | 1,628,256/s | **2.31x** |\n| 10,000 | Unique glob | 69,704/s | 310,112/s | **4.54x** |\n\nThis rerun also corrected the old `55.7x` headline. The historical glob\ngenerator reused only five effective URL shapes, so the 10,000-route tier put\n100 terminal entries behind each shape. That result measured a real\nduplicate-route edge case, but it was not a clean 10,000-unique-route\ncomparison and is no longer a general Amber V2 claim.\n\nRead [the complete benchmark explanation](/blog/2026/08/13/amber-v2-router-on-a-four-dollar-droplet),\ninspect the [machine-readable paired summary](/benchmarks/amber-v2-router-digitalocean-2026-08-13-summary.json),\nor download the [168 raw trials](/benchmarks/amber-v2-router-digitalocean-2026-08-13-raw.jsonl).\n\n## Published evidence\n\nThe [round 22 summary data](/benchmarks/amber-v2-round22-summary.json) records\nthe result, workload, source commit, request-table hash, and hardware boundary\nin a machine-readable form. The source experiment used commit\n`deccb9358fd378a8d4e060cd13a19a35c609197e`; the runner used commit\n`744269f4fa83ea5a5cbbbeef58d541d0981171d1`.\n\nThe result should be rerun for the GA release. If the workload, hardware, or\nharness changes, publish it as a new benchmark rather than silently replacing\nthe historical context.\n\nThe separate [August 11 website evidence](/benchmarks/amber-v2-site-websocket-2026-08-11.json)\nrecords what the actual public-site release candidate did under both HTTP and\nheld-WebSocket load. Keep these two workloads separate when quoting them."}