Skip to content

Add Server-Timing instrumentation and optimization plan#322

Draft
prk-Jr wants to merge 4 commits intomainfrom
feat/optimize-ts
Draft

Add Server-Timing instrumentation and optimization plan#322
prk-Jr wants to merge 4 commits intomainfrom
feat/optimize-ts

Conversation

@prk-Jr
Copy link
Collaborator

@prk-Jr prk-Jr commented Feb 18, 2026

Summary

  • Add RequestTimer (crates/common/src/request_timer.rs) that tracks init, backend, process, and total phases and emits a Server-Timing response header
  • Wire timer into main.rs and publisher.rs for the publisher proxy hot path
  • Add scripts/benchmark.sh with --profile mode to collect and report Server-Timing data, TTFB/TTLB stats, and load test results
  • Add OPTIMIZATION.md — phased optimization plan for team review covering:
    • Phase 0: Deploy Server-Timing instrumentation (done, needs deploy)
    • Phase 1: Low-risk code fixes (gzip streaming, HTML rewriter streaming, logging)
    • Phase 2: stream_to_client() streaming architecture (needs spike for #[fastly::main] compatibility)
    • Open design questions and decisions needed from the team

Test plan

  • Deploy feat/optimize-ts to staging
  • Run BENCH_URL=<staging-url> ./scripts/benchmark.sh --profile and verify Server-Timing headers appear
  • Verify no regression on existing endpoints (static, auction, discovery, publisher proxy)
  • Team review of OPTIMIZATION.md — especially "Decisions Needed" section

Introduce RequestTimer for per-request phase tracking (init, backend,
process, total) exposed via Server-Timing response headers. Add
benchmark tooling with --profile mode for collecting timing data.
Document phased optimization plan covering streaming architecture,
code-level fixes, and open design questions for team review.
Introduce RequestTimer for per-request phase tracking (init, backend,
process, total) exposed via Server-Timing response headers. Add
benchmark tooling with --profile mode for collecting timing data.
Document phased optimization plan covering streaming architecture,
code-level fixes, and open design questions for team review.
@aram356
Copy link
Collaborator

aram356 commented Feb 18, 2026

@prk-Jr Have you seen this? https://www.fastly.com/blog/profiling-fastly-compute-applications

I don't think we need to make changes to profile

RequestTimer and Server-Timing header were premature — WASM guest
profiling via profile.sh gives better per-function visibility without
runtime overhead. Also strips dead --profile mode from benchmark.sh.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Comments