Science & Theses
Investigating the mathematical and physical limits of single-process execution, queueing singularities, and memory compaction under extreme hardware constraints.
The scientific frameworks presented here are working theoretical theses, mathematical formalisms, and hardware-verified models developed by LevioraLabs. All benchmark metrics have been physically measured within strictly isolated Linux containers (1 vCPU / 1 GB RAM and 2 vCPU / 2 GB RAM). These are rigorous exploratory models intended for low-overhead edge cloud architectures.
Queueing Theory & The Kingman Singularity in Edge Runtimes
The Problem: Exponential Tail Latency Avalanche
According to Kingman's heavy-traffic approximation in G/G/1 queueing systems, expected waiting time explodes asymptotically as utilization ρ approaches 1.0. In single-threaded event loops running on a single CPU core, accepting bursts beyond capacity causes queue buildup, starving garbage collection and causing complete thread collapse.
The Leviora Hypothesis: Ingress Shedding & Boundary Clamping
By implementing an O(1) in-memory atomic token-bucket at the socket ingress layer, non-critical traffic exceeding 82% utilization is preemptively rejected within 0.05ms (HTTP 429). This prevents queue buildup, isolates the execution core from CPU starvation, and guarantees bounded p99 response times for prioritized traffic.
E[W_q] ≈ (ρ / (1 - ρ)) · ((c_a² + c_s²) / 2) · (1 / μ), where ρ = λ / μ ≤ 0.82Where λ is arrival rate, μ is service rate, c_a and c_s are arrival/service variance coefficients. Bounding ρ ≤ 0.82 prevents the denominator (1 - ρ) from collapsing to zero, eradicating tail latency divergence.
Physical Benchmark · 4,000 HTTP Burst Ingress Under CPU Saturation
Physically measured inside isolated Docker cgroup containers under 1 vCPU / 1 GB RAM vs 2 vCPU / 2 GB RAM.
| Hardware Tier | Total Load | Throughput | Total Time | p50 Latency | Overload Mitigated | Process State |
|---|---|---|---|---|---|---|
| Tier 1 (1 vCPU, 1 GB RAM) | 4,000 requests | 340 req/s | 11.75 s | 82.97 ms | 288 requests (<0.05ms) | Stable · Zero Crash |
| Tier 2 (2 vCPU, 2 GB RAM) | 4,000 requests | 542 req/s (+59.4%) | 7.37 s (-37.2%) | 47.97 ms (-42.2%) | 229 requests (<0.05ms) | Optimal · Instant Recovery |
* Second CPU core delivers +59.4% throughput and cuts median response latency nearly in half by unblocking event thread pools.
Thermodynamics of Memory Allocators & V8 Heap Compaction
The Problem: The Memory Tax of Separate OS Processes
Modern serverless and multi-tenant architectures rely on containerized child processes (fork/exec). Each spawned process replicates the base C runtime (glibc), V8 engine bytecode caches, and memory page tables (~38.5 MB per worker). Under a strict 1 GB memory ceiling, allocating more than 24 workers inevitably triggers the Linux kernel Out-Of-Memory (OOM) killer.
The Leviora Hypothesis: Clamped Isolate Threading
By consolidating workers into a single process using Node.js Worker Threads with an explicit 16 MB heap ceiling (−−max-old-space-size=16) and aggressive Scavenger GC cycles, the base memory footprint per worker drops to 8.85 MB. This allows a 1 GB server to host 102 concurrent tenant workers without risking memory exhaustion.
N_{max} = ⌊ (M_{RAM} - M_{system}) / (M_{V8\,runtime} / k + M_{clamped\,heap}) ⌋Where k is the thread sharing coefficient (k >> 1 for in-process threads vs k = 1 for OS process forks). Sharing the V8 runtime lowers memory footprint by 77%.
Physical Benchmark · 40 Concurrent Workers Memory Footprint & Cold-Start
Measured across 40 concurrently active workers executing compute cycles in isolated containers.
| Execution Model | Hardware Tier | Cold-Start Delay | Average RSS / Worker | Max Worker Capacity (Safe) | Memory Savings |
|---|---|---|---|---|---|
| Process Fork (Baseline) | 1 vCPU / 1 GB RAM | 420.0 ms | 38.50 MB | ~24 workers (OOM risk) | Baseline (0%) |
| Leviora Clamped Workers | Tier 1 (1 vCPU, 1 GB RAM) | 378.5 ms | 8.85 MB | 102 workers (+325%) | -77.0% RAM |
| Leviora Clamped Workers | Tier 2 (2 vCPU, 2 GB RAM) | 146.4 ms (-61.3%) | 9.07 MB | 210 workers (+775%) | -76.4% RAM |
* 2 vCPU accelerates worker cold-start by 2.58x (146.4ms vs 378.5ms) due to parallel bytecode JIT compilation across cores.
Write Amplification Reduction & Memory-Mapped Page Convergence
The Problem: Rollback Journal Dual-Write Penalty
In default SQLite configurations, every transaction initiates a dual-write cycle: dirty pages are written to the rollback journal, fsync() blocks execution, the database file is mutated, and another fsync() executes. This results in a Write Amplification Factor (WAF) exceeding 2.2, severely degrading SSD longevity and introducing millisecond-level wait locks.
The Leviora Hypothesis: WAL Sequential Append & 512MB MMAP
By switching to WAL (Write-Ahead Log) mode with sequential append writes, relaxed synchronization (synchronous=NORMAL), and memory-mapping 512 MB directly into userspace address space (PRAGMA mmap_size=536870912), the engine bypasses file system buffer copy loops, bringing read latency down to 3.2 microseconds.
WAF = (Bytes written to physical storage) / (Bytes written by user payload) → lim_{WAL} WAF ≈ 1.05WAL mode converts random B-tree mutations into sequential log appends, reducing hardware block wear and eliminating redundant page flushes.
Physical Benchmark · 20,000 Writes & 100,000 Reads Across Storage Modes
Synchronous transactional execution with indexed key-value reads in isolated test containers.
| Engine Mode | Hardware Tier | Write Throughput | Read Throughput | p50 Latency | p95 Latency |
|---|---|---|---|---|---|
| Default Disk Journal | Tier 1 (1 vCPU, 1 GB) | 30,712 ops/s | 72,580 ops/s | 13.8 µs | 19.5 µs |
| Default Disk Journal | Tier 2 (2 vCPU, 2 GB) | 34,916 ops/s | 74,800 ops/s | 13.4 µs | 18.9 µs |
| Leviora Extreme (WAL+MMAP) | Tier 1 (1 vCPU, 1 GB) | 31,040 ops/s | 118,450 ops/s | 3.6 µs | 6.1 µs |
| Leviora Extreme (WAL+MMAP) | Tier 2 (2 vCPU, 2 GB) | 32,250 ops/s | 122,264 ops/s | 3.2 µs | 5.7 µs |
| Pure In-Memory (:memory:) | Tier 2 (2 vCPU, 2 GB) | 207,936 ops/s | 261,673 ops/s | 3.3 µs | 5.8 µs |
* WAL + MMAP provides 1.68x faster read throughput than standard journals on persistent storage, while memory mode achieves 207k writes/sec with zero disk bottlenecks.
Laboratory Reproducibility: Open Docker Harness
Scientific integrity demands that every measurement reported by LevioraLabs is independently reproducible by any external engineer. All benchmarks in these theses were physically evaluated inside isolated, network-blinded Linux containers with strict cgroup v2 hardware quotas.
docker run --rm -it --network=none --cpus=1.0 --memory=1g node:22-trixie-slimdocker run --rm -it --network=none --cpus=2.0 --memory=2g node:22-trixie-slim--network=none cuts all external egress, eliminating outside cloud variance or security concerns.
Container state immediately destroys itself upon exit, leaving zero disk or memory footprint.
Hard CPU shares and memory envelopes prevent noisy-neighbor effects or host exhaustion.