blitz_platform_api/
counters.rs

1//! What the platform APIs moved, counted where this crate can see it.
2//!
3//! # These are not boundary bytes, and the distinction matters
4//!
5//! `blitz-wasm`'s [`Counters`] count bytes crossing the *guest* boundary: read
6//! out of, or written into, wasm linear memory. The numbers here count bytes
7//! crossing the *network and storage* boundary: what a request body carried,
8//! what a response body brought back, what a storage value weighed.
9//!
10//! For one fetch they are usually close and never guaranteed equal. A guest
11//! that starts a request and never reads the body moved 40 KB here and zero
12//! there. A guest that reads the same body twice moved 40 KB here and 80 KB
13//! there. Adding them would produce a number answering no question, which is
14//! why they are separate types in separate crates rather than more fields on
15//! one struct.
16//!
17//! Both exist because the brief asks for fetch bytes to be attributable
18//! separately from DOM bytes in both directions. This half answers "what did
19//! the platform move"; the binding's half answers "what did that cost at the
20//! boundary".
21//!
22//! # No timing
23//!
24//! Same reason `blitz-wasm` gives: a duration measured on one machine, in one
25//! build profile, is not evidence. A byte count is the same everywhere. A fetch
26//! duration is additionally dominated by the network, which is the one part of
27//! the system no design decision here changes.
28//!
29//! [`Counters`]: ../../blitz-wasm/src/counters.rs
30
31/// Everything one [`PlatformHost`](crate::PlatformHost) has moved.
32#[derive(Debug, Clone, Copy, Default, PartialEq, Eq)]
33pub struct PlatformCounters {
34    /// Requests handed to the provider.
35    pub fetches_started: u64,
36    /// Requests drained from the ready queue.
37    ///
38    /// Counts failures as well as responses: a request that could not be
39    /// completed still completed, in the sense the queue means. The gap between
40    /// this and `fetches_started` is the number still in flight, plus any
41    /// released before they were drained.
42    pub fetches_completed: u64,
43    /// Request-body bytes handed to the provider.
44    ///
45    /// Counted at [`start_fetch`](crate::PlatformHost::start_fetch), so it
46    /// counts what was submitted rather than what reached a server. A request
47    /// that failed to connect still counted its body here, which is correct for
48    /// the question "what did the guest ask us to send".
49    pub fetch_bytes_sent: u64,
50    /// Response-body bytes, counted once per request when it is drained.
51    ///
52    /// Once, not once per read: a guest reading the same body twice has moved
53    /// twice the bytes across its own boundary, and that is the binding's
54    /// counter to keep. Headers are not counted, because a provider may
55    /// synthesise them (`data:` URLs) and a compressed transfer never carried
56    /// the bytes the header map now holds.
57    pub fetch_bytes_received: u64,
58
59    pub storage_reads: u64,
60    /// Every call that could change the store: `set`, `remove`, `clear`.
61    ///
62    /// A `remove` of an absent key and a `clear` of an empty origin are counted
63    /// even though nothing changed, because this crate does not ask the
64    /// provider whether anything did. It is a count of calls, not of edits.
65    pub storage_writes: u64,
66    /// Value bytes returned by `get`. A miss adds nothing.
67    pub storage_bytes_read: u64,
68    /// Key plus value bytes accepted by `set`. A rejected write adds nothing.
69    pub storage_bytes_written: u64,
70}
blitz_platform_api/counters.rs

blitz_platform_api/
counters.rs
