Who this is for

You want a quick feel for how fast Pionia Shop handles a warm GET ping or a Moonlight dispatch on your machine — before you reach for load testers or RoadRunner profiling.

What you will learn

  • Run php pionia bench (alias benchmark)
  • Read mean / p50 / p95 and ops/sec
  • What this command measures (and what it does not)

Before you start

Before you start
  • A Pionia Shop (or any Pionia) app with php pionia working
  • Optional: a service/action you care about (default is auth / list_auth)

How it works

bench boots the application once, warms the process, then times repeated in-process calls:

  1. HTTP-shaped ping via handleRequest (no TCP server)
  2. Moonlight dispatch(service, action) for the pair you choose
flowchart LR
  CLI["php pionia bench"] --> Boot[AppRealm once]
  Boot --> Warm[Warmup iterations]
  Warm --> Ping[Time ping]
  Warm --> ML[Time moonlight dispatch]
  Ping --> Stats[mean / p50 / p95]
  ML --> Stats

Not a load test

This is a microbenchmark of a warm PHP process. It does not open sockets, exercise nginx/FPM, or simulate concurrent users. For request metrics under real traffic, use Developer stats or an external load tool.

Run it

Terminalbash
php pionia bench
php pionia bench --iterations=200 --warmup=20
php pionia bench --service=task --action=list --json
OptionDefaultPurpose
--iterations100Timed runs per probe
--warmup10Discarded runs before timing
--serviceauthMoonlight service alias
--actionlist_authMoonlight action name
--jsonoffMachine-readable output

Example terminal output (numbers vary by machine):

Outputtext
Ping (handleRequest)
  mean  0.42 ms   p50  0.38 ms   p95  0.71 ms   2380 ops/s

Moonlight dispatch (product.list)
  mean  0.85 ms   p50  0.79 ms   p95  1.20 ms   1176 ops/s

When to use it

Use bench when…Prefer something else when…
Comparing two code paths on the same laptopYou need concurrent users or HTTP latency
Checking that a change did not explode warm dispatch costYou are tuning SQL — use Porm performance
Capturing a JSON snapshot in CI smokeYou need production OPcache — see Production performance

Common mistakes

  • Treating ops/sec as production capacity — one warm worker ≠ fleet throughput.
  • Benchmarking a cold first request only — use enough --warmup so OPcache and autoload settle.
  • Pointing at a missing service/action — register the pair on your switch first, or stick to auth / list_auth from the template.

What’s next

Developer stats

Request metrics at /stats and stats:view.

Production performance

OPcache preload and optimize --production.

Commands

Full CLI registry.