Seeing what a page cost

Summary#

The dev panel's Net tab shows, for every call your app made: how long it took and what the server did to answer it — the database round trips, the statements they carried, and how much of the time was spent waiting on SQL.

A millisecond number on its own cannot tell you whether 340ms was one query or nineteen, and that is usually the question worth asking. The count makes it visible without having to suspect it first.

Signature#

Ctrl+Shift+D  →  Net           the panel, on any page served by the local platform
window.__osy.net                the same rows as data, for a script or an agent

Each row reads:

GET   200   /api/data/Contact       41ms   19rt/27q   23ms sql   9f3c…
                                    └ wall  └ round     └ of which  └ correlation id
                                      clock   trips       waiting
                                              /statements on SQL

Description#

19rt is the number: NETWORK ROUND TRIPS. Not statements, and the two are not the same count — the platform pipelines, so a batch of forty statements is one trip. The row shows the statements alongside whenever they differ (1rt/40q), because that gap is the batching and 1rt on its own reads better than it deserves.

⚠ Do not call either of them "queries". Round trips are what latency is made of and what this page is about; the statement count is a different question, and a read-in-a-loop that got batched hides in the first and shows in the second.

23ms sql tells you which of two problems you have. Close to the row's total: the time is round-trip latency, and the fix is fewer, bigger queries. Far below it: the time went somewhere else — CPU, or waiting on something that is not the database — and the query count is not your bug however large it looks.

A count is only meaningful against what the call was for. Nineteen queries to paint a report page is ordinary; nineteen behind a button press is usually a read inside a loop. The panel tints a high count as a nudge to look, not as a verdict.

The query shapes are deliberately not here. They are in the server log, under the correlation id on the same row:

make logs-corr ID=9f3c1a2b-…

That line carries the top shapes by frequency and by rows — the second ranking matters because one unfiltered read of a big table is a single round trip and never appears in a by-frequency list, while being most of the work. Keeping one copy of the shapes is why the panel shows the number and the log shows the detail.

Local dev host only. The X-Osy-Db header this reads is emitted only by a platform started with osy launch / osyrin dev, on the same gate as the panel itself. A deployed host sends nothing: in production a query-shape description is free information to anyone with a browser, for the benefit of nobody. On a host that does not send it the field reads as not measured, never as zero.

What it counts is the request, all of it — everything the call awaited, including work in functions it invoked. The one thing outside the number is a query issued while the response body is being written; nothing in the platform does that today (rows are materialised before they are serialised).

Examples#

Find the page that got slow, from a script:

// syntax — the dev handle is a browser global, not Osy# source.
window.__osy.net
  .filter((c) => c.db && c.db.net >= 10)
  .map((c) => `${c.method} ${c.url} — ${c.ms}ms, ${c.db.net} queries, ${c.db.sqlMs}ms sql`);

Then read the shapes behind the worst one:

make logs-corr ID=<the correlation id on that row>

See also#

• Seeing what happened when your code ran — osy inspect, for what the code did rather than what it cost
• Recording a run — osy trace, when you need the steps and not the totals
• Running a local platform — the host that emits this