← back
Client→ALB → ECS→Node→Postgres

Where your requests
actually go

Every request threads through layers owned by different things — the kernel, the runtime, your framework. This lab shows where they wait.

  1. 1
    Configure the stack — runtime, hosts, pools and limits.
  2. 2
    Send a burst of requests through it.
  3. 3
    See which layer holds them — that's the bottleneck.
Any language
Kernel, sockets, database
Runtime specific
libuv, V8, one thread
Framework
Middleware, routing, the pool

Stack

Runtime
Host
1
4
20
In front of Node
Database
10
Limits per task
1 GB
65,536

Load

1,000
5 s
5
Trace one request
Follow one request through every layer. Play auto-advances; Back / Next (or ← →) step through it. Toggle per req / total to read a single request or the whole burst.
Request → flows through each layerclick any layer to inspect it
◀Response returns along the same path
Click a group, or press Play.

Where the time went

GroupAvg / reqSharePeakNow
Fire a burst to profile it.

Cold vs warm

BurstReusedHandshakesOverflowFirst byteWall clock
Fire twice within the keep-alive window.

Runtime comparison — same box, same load

config changed — re-run to update

Runs the current configuration through Node, PHP, Java and Go and reports where each one loses its time.

RuntimeWall clockCPU usedPeak memoryReq / sWhy

Ranked on the box configured above. Change anything and re-run.

Keywords