Enterprise packet investigation · Performance

Find where the transaction actually slows down.

Compare slow exchanges with healthy baselines and separate transaction waterfalls, excessive TCP turns, VoIP jitter, Wi-Fi retries, network recovery, and service wait—without blaming the network or application by default.

Transaction performanceslow-vs-healthy.pcap

Baseline available

CAPTURED TRANSACTION2.84 sHealthy baseline: 940 ms
025%50%75%END
DNS42 ms
TLS180 ms
API410 ms
Dependency1.74 s
Response468 ms
Setup Transfer Dominant interval

Performance question

Which dependency holds up the transaction?

Packet-grounded findingOne downstream exchange dominates the captured request waterfall.
Boundary
The packets identify the slow dependency and interval; internal service execution still requires application evidence.
Filter
http2.streamid || http.request_in || tcp.stream == 184
Evidence
Slow transaction · healthy baseline · exact frames and stream

Timings describe the captured path and vantage point. They do not automatically assign internal application or infrastructure ownership.

Explanatory timing scenarios; conclusions remain capture- and vantage-specific.

One transaction, every captured interval

Stop debating the slow tier. Measure the exchange.

PacketSafari Core Engine discovers reusable timing and transport evidence. Agent explains the strongest comparison and preserves the uncertainty boundary.

  1. 01Name resolution

    DNS retries, resolver delay, response errors, and healthy baselines.

  2. 02Connection setup

    TCP establishment, TLS handshake stages, resets, and negotiation delay.

  3. 03Transport quality

    Retransmissions, duplicate ACKs, RTT, reordering, windows, stalls, and MTU evidence.

  4. 04Application exchange

    Request-to-first-byte timing, transaction waterfalls, excessive turns, server wait, and response transfer.

  5. 05Real-time media

    RTP sequence, loss, jitter, arrival spacing, and healthy-call comparison.

  6. 06Wireless airtime

    802.11 retries, contention, signal context, data rates, and capture-vantage limits.

Responsible performance attribution

A timing spike is evidence. Ownership still requires proof.

01

Network primary cause

Captured network behavior is sufficient to explain the dominant delay.

02

Network contributing factor

Network behavior materially increases time but does not explain the entire transaction.

03

Service-side wait

The long interval follows a complete request and precedes the captured response.

04

Receiver or client constraint

Advertised windows or client behavior align with the captured stall.

05

Inconclusive capture

The vantage, baseline, or required exchange is insufficient for responsible attribution.

PacketSafari can localize delay to the captured exchange. Internal application code, infrastructure policy, and uncaptured hops require the next corroborating source.

Performance investigation ROI

Reduce the hours spent arguing about where the time went.

MONTHLY VALUEHours saved per investigation × investigations per month × blended team cost
  1. 01Time to isolate the slow tier
  2. 02Performance-war-room hours
  3. 03Network, application, and vendor handoffs
  4. 04Time from complaint to corrective action
  5. 05Repeated incident and specialist-escalation hours

Measure the same incidents and acceptance criteria against the current workflow. PacketSafari does not claim a universal performance-analysis speedup.