Performance, Tracing & APM

Performance page

Per route/job: p50 / p75 / p95 / p99, average and max duration, throughput (TPM), failure rate and Apdex. Route names are normalized (/user/123 → /user/:id) so endpoints group. Stats are read from pre-aggregated hourly rollups (a duration histogram per route × hour), so percentiles stay accurate at any volume. Click any route to open its Transaction Summary — percentile tiles, throughput & p95 charts, the perf issues detected in it, and its slowest + most recent traces.

Traces & the waterfall

The Trace Explorer searches across traces; each trace renders as a waterfall with the real span tree (children nested under parents via parent_span_id), a time ruler, op-colored bars, red bars for failed spans, and cross-service stitching by trace id.

Click any span to open its detail drawer: the full untruncated description (the complete SQL / URL), op, status, duration, span id, and a table of every span attribute (db.system, db.statement, http.url, http.response.status_code, cache.hit, …) — the same semconv attributes your SDK or OpenTelemetry exporter sends.

Automatic performance issues

jentry detects five performance pathologies from your spans and files each as a Performance issue (they alert, assign and resolve like any issue):

• N+1 Query — the same parameterized db/cache statement repeated ≥5× in one transaction (duration-gated to skip trivial repeats).
• N+1 API Call — repeated outbound HTTP to the same templated endpoint (ids collapse: /users/:id).
• Slow DB Query — a single db span over ~1s.
• Consecutive DB Queries — ≥3 independent DB queries run one-after-another (serialized) that could be issued concurrently.
• Consecutive HTTP Calls — the same, for independent outbound HTTP requests made serially.

Each issue carries Span Evidence: the transaction, operation, the offending span(s) (syntax-highlighted), the repeat/serialized count, total duration and estimated recoverable time — plus an example trace with the offending spans highlighted, and a targeted suggested fix (batch/eager-load for an N+1, parallelize for a consecutive run, index/narrow for a slow query).

Service Map

The Service Map (a tab on Performance) draws your topology from distributed traces: one node per service (OpenTelemetry service.name, or the tags.service on your transactions), with an edge wherever one service's span calls another service's transaction in the same trace. Nodes show tx volume + avg duration, edges show call counts + callee latency, and anything failing over ~5% turns red.

Insights, Web Vitals & Performance Score

Insights aggregates spans into modules — DB queries, HTTP requests, caches (hit rate), queues, mobile vitals — ranked by time spent. Browser SDKs feed Web Vitals (LCP/CLS/INP/FCP/TTFB) with good/poor thresholds, and jentry rolls those into a Performance Score — a 0–100 composite ring using Google's log-normal methodology and Lighthouse weights, with a per-vital breakdown.