# Resource profile v1

WSL2 Ubuntu x86_64, ext4 temporary directory, Linux 6.6.87.2-microsoft-standard-WSL2, Rust 1.90.0, Python 3.12.3. Built the 977,784-byte release CLI with the workspace LTO and strip settings. The machine also ran other development work. Each column represents one fresh server and database. Timings include OS scheduling.

## Local server and client

| Observation | 100 documents | 1,000 documents |
|---|---:|---:|
| Launch to listening on empty initialized file | 13.73 ms | 10.20 ms |
| Ready RSS (smaps_rollup) | 2,584 KiB | 2,580 KiB |
| Idle CPU ticks in 5 seconds (100 ticks/s) | 0 | 0 |
| Connect + authenticate | 21.86 ms | 25.35 ms |
| Authentication peak RSS (VmHWM) | 21,696 KiB | 21,696 KiB |
| RSS after authentication | 2,732 KiB | 2,768 KiB |
| Durable insert, mean | 8.680 ms | 6.075 ms |
| 32 durable field updates, mean | 9.488 ms | 7.970 ms |
| 128 point reads, median | 0.120 ms | 0.142 ms |
| 16 bounded scans, mean (100 documents returned per scan) | 0.459 ms | 0.439 ms |
| RSS immediately before / after scans | 2,760 / 3,088 KiB | 2,796 / 3,124 KiB |
| Peak RSS over server lifetime through last scan | 21,696 KiB | 21,696 KiB |
| Insert-phase process write_bytes | 2,797,568 B | 184,979,456 B |
| Logical / allocated file bytes after updates | 33,554,432 / 73,728 | 33,554,432 / 704,512 |

The client stored one event object with a 256-byte text field per six-digit ID. Each insert and update was one authenticated loopback request with its own commit. Wall-clock latency includes Python, JSON encoding/decoding, socket traffic and server work. The scan retains its bounded result array before transmitting it. RSS includes thread stacks, code and allocator retention. VmHWM covers the whole server since spawn, including Argon2id verification. Two small changes in RSS cannot isolate transient scan allocations. Zero charged ticks means CPU use fell below observable resolution in these samples. It does not guarantee zero idle CPU.

Linux procfs write_bytes measures storage writes attributed to the process, including filesystem writeback behavior. The count excludes work charged elsewhere and cannot measure NAND writes or wear. st_blocks gives allocated filesystem blocks for the data file alone. Neither the Python client nor the filesystem page cache is charged to the reported server RSS.

```sh
cargo build --locked --release -p ratdb-cli
python3 -B scripts/profile_server_linux.py target/release/ratdb
```

Use `--records 100 1000` to select cardinalities. The script creates temporary files and uses an ephemeral loopback port. With `CARGO_TARGET_DIR=target/linux`, pass `target/linux/release/ratdb`.

## Constrained embedded heap

A second release executable compares operations over the same v1 bytes using a counting Rust system allocator. The simulated medium has 8,192 logical bytes with two 4,096-byte banks. Cache entries are disabled, key length is capped at 32 bytes and value length at 160 bytes. Sixteen compact JSON records contain an ID, a boolean and an integer reading. Each serialized value is 39 bytes. The baseline is sampled immediately before each call. Peak bytes above baseline include the returned value until the operation finishes.

| Operation | Peak extra heap | Allocation calls |
|---|---:|---:|
| Raw point read | 113 B | 28 |
| JSON point read | 705 B | 35 |
| Replace identical encoded bytes | 113 B | 64 |
| Parse JSON input and replace | 907 B | 74 |
| Raw streaming scan | 113 B | 48 |
| JSON scan, drop each parsed document | 715 B | 130 |
| JSON scan, retain all 16 parsed documents | 10,977 B | 133 |
| Validate and recover after an injected flush error | 113 B | 48 |

The adapter holds two RAM images totaling 16,384 bytes to simulate volatile writes and durable storage. Those buffers are already resident at each baseline. The recovery check discards unsynced memory, reopens the durable image, verifies the previous bytes and checks the record count. The heap figure covers recovery allocations above baseline. It excludes the simulated medium, stack, allocator overhead and code. Record limits bound input sizes. These results do not establish a process-wide memory cap or predict the peak for larger or more deeply nested documents.

```sh
cargo run --locked --release -p ratdb-document --example heap_profile
```

The server and embedded results were obtained on an AMD Ryzen 9 9900X. The example and probe use separate processes. Run both on the intended storage and CPU before selecting application limits.