capcalc

A small, dependency-free Python library + CLI to estimate CPU (vCPU) and RAM (GiB) for different system types.

It uses a unified sizing idea:

• CPU is derived from effective throughput × CPU cost per unit ÷ target utilization, with overhead + headroom.
• RAM is derived from baseline + concurrency/state growth, with overhead + headroom.

Accuracy depends on accurate inputs (load tests/metrics). The library tries to be "precise" mathematically and strict about units.

NCI

NCI stands for Normalized Capacity Index. It’s a sizing method (and a metric idea) that turns real workload inputs into CPU (vCPU) and memory (RAM) requirements in a consistent way across different system types.

What NCI tries to solve

Most “CPU and RAM calculators” fail because they ignore one or more of these realities:

• Traffic isn’t constant: it has bursts (peaks).
• CPU cost is tied to work per unit (per request, per message, per event), not just “users.”
• Memory often grows with concurrency/state, not directly with RPS.
• Production needs safety: overhead, headroom, and target utilization.

NCI combines those into a single, repeatable structure.

---

Core idea

NCI says:

1. Convert your average load into effective peak load.
2. Convert peak load into CPU cores using measured CPU time per unit of work.
3. Convert peak load into concurrency (how many things are in-flight at the same time).
4. Convert concurrency into RAM using baseline memory + incremental memory per in-flight unit.
5. Apply realistic multipliers: overhead + headroom + utilization targets.

---

The NCI CPU sizing logic

Meaning: “How many CPU-seconds per second do I need at peak, after overhead and safety margins?”

---

The NCI memory sizing logic

Concurrency is estimated using a queueing principle (Little’s Law): [ Conc \approx RPS_{eff}\times T_{resp} ]

Memory is then: [ RAM = \frac{(MEM_{base} + Conc\times MEM_{per_conc})\times OH_{mem}\times Headroom_{mem}}{U_{mem_target}} ]

Meaning: “How much memory do I need for the baseline process plus what grows with in-flight work, again with safety margins?”

---

Why it’s “normalized”

It’s “normalized” because the same structure works across many systems:

• Web/API: unit = request
• Worker/Queue: unit = message
• Stream processor: unit = event
• Batch: unit = job slice over a time window

You always model: (effective load) × (cost per unit) → resources, then normalize with utilization targets and safety factors.

Install

cd capcalc_lib
python -m pip install -e .

or

python3 -m pip install "capcalc @ git+https://github.com/CyberSecurityUP/CapCalc.git"

Quick usage (Python)

from capcalc.models.web import WebServiceModel

m = WebServiceModel(
    name="api",
    rps_avg=200,
    burst_factor=2.5,
    cpu_ms_per_req=6,
    resp_time_s=0.25,
    mem_base_mb=600,
    mem_mb_per_concurrent=3,
)
report = m.size()
print(report)

CLI (JSON)

capcalc plan.json

Example plan file: examples/plan.json