test(perf): first_prompts is not the /api/day bottleneck (harness only)#154
Merged
Conversation
…bottleneck Follow-up to PR #153 suspected first_prompts dominated /api/day (~95ms of ~108ms end-to-end). Measured directly: first_prompts is ~6ms for ~188 sessions and the endpoint is ~31ms server-side (raw HTTP). The earlier ~108ms was PowerShell Invoke-RestMethod deserializing the 4.6KB response into objects — a client-side artifact absent in the app, whose JS frontend parses the payload natively in <1ms. No query change warranted: rewriting the windowed query to GROUP BY MIN(timestamp) would risk the identical-timestamp tie case for ~4ms on an endpoint already under the 50ms target. Add the first_prompts timing + EXPLAIN to perf_probe so the finding stays measurable. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Finding
Follow-up to #153. The chip suspected
first_promptswas the dominant/api/daycost (~95ms of a ~108ms end-to-end). Measured directly, that was a measurement artifact:first_prompts(188 session ids)/api/dayserver-side, raw HTTP (no parse)/api/health)Invoke-RestMethodparse overhead (PowerShell)The earlier ~108ms came from PowerShell's
Invoke-RestMethoddeserializing the response into objects — a client-side cost absent in the app (the JS frontend parses the 4.6 KB payload natively in <1 ms). True server-side/api/dayis ~31 ms warm, already under the 50 ms target.Decision: no query change
first_promptsat 6 ms isn't worth rewriting. AGROUP BY MIN(timestamp)+ join would risk the identical-timestamp tie case for a ~4 ms gain on an endpoint already fast.What this PR does
Adds a
first_promptstiming + EXPLAIN to theperf_probeexample so the finding stays measurable. No production code touched.Verification
cargo fmt --check+cargo clippy --examples -D warningsclean. Lesson recorded in the spec: measure server endpoints with a raw byte fetch, notInvoke-RestMethod.🤖 Generated with Claude Code