Repository navigation
Conversation
Alert messages printed the raw average ("High response time:
2096.285714285714ms") and formattedMessage the raw actualValue; both are
rounded now, and actualValue keeps the exact figure.
The cache hit rate read differently across tools in the same minute
(stats 6.3%, alerts 2%, site1 16.7%) because each has its own scope: all
sites combined since server start, the value when an alert was raised,
or a single site. Nothing said which. wp_performance_stats (cache,
siteSpecific), wp_performance_alerts, wp_performance_history,
wp_cache_stats and wp_cache_info now carry a scope label, and the
siteSpecific hit rate is a percentage like everywhere else.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Reviewer's GuidePolishes performance alert numbers and makes cache hit-rate scope explicit across aggregate, per-site, alert, historical, and cache-tool responses, with documentation and regression coverage for the changed output shapes. Sequence diagram for scoped performance outputsequenceDiagram
participant Caller
participant PerformanceTools
participant CacheTools
participant AlertTools
participant Metrics
Caller->>PerformanceTools: getPerformanceStats()
PerformanceTools->>Metrics: collect aggregate metrics
Metrics-->>PerformanceTools: all-site cache hit rate
PerformanceTools-->>Caller: cache with all-sites scope
Caller->>PerformanceTools: getPerformanceHistory()
PerformanceTools->>Metrics: read snapshots
Metrics-->>PerformanceTools: timeframe snapshots
PerformanceTools-->>Caller: summary with average scope
Caller->>CacheTools: getCacheStats()
CacheTools->>Metrics: read site cache counters
Metrics-->>CacheTools: one-site hit rate
CacheTools-->>Caller: cache_stats with site scope
Caller->>AlertTools: getPerformanceAlerts()
AlertTools-->>Caller: recorded alerts and activeAlerts scopes
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e6bea5ade7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Some hit-rate outputs remain unlabeled, and history scope conflates the selection window with session-cumulative metrics.
2 open findings
What changed in this PR
Polishes cache/performance output by clarifying metric scope and rounding alert values.
Changes:
- Adds scope labels to cache, performance, history, and alert responses.
- Rounds displayed alert values while preserving raw values.
- Adds regression tests and performance documentation.
| File | Description |
|---|---|
src/performance/AGENTS.md |
Documents scope and rounding contracts. |
src/performance/PerformanceMonitor.ts |
Rounds response-time alert messages. |
src/tools/cache.ts |
Labels site-specific cache statistics. |
src/tools/performance/PerformanceHelpers.ts |
Rounds formatted alert values. |
src/tools/performance/PerformanceTools.ts |
Adds scope labels and formats per-site rates. |
tests/performance/OutputScope.test.js |
Tests scope labels and rounding. |
tests/tools/cache.test.js |
Updates cache response assertions. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…tals Review follow-up. wp_performance_benchmark, wp_performance_optimize and wp_performance_export (all three formats, via the outer metadata) now carry a scope too, and wp_performance_alerts labels its anomalies. wp_performance_history summed requests.total over its snapshots, but every snapshot holds a total since server start, so three snapshots of 100, 150 and 230 reported 480 requests. It now reports the 130 made between the first and last snapshot, and the summary scope says the averages are over cumulative figures. docs/PERFORMANCE_MONITORING.md documents the scopes and the siteSpecific.cache.hitRate percentage string. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
14 of 15 tasks
…window
Review follow-up:
- formattedMessage rounded rates to 2 decimals, so an error rate of
1/19 printed as "0.05 vs threshold: 0.05". Values below 1 keep 3
significant digits, and more if they would still equal the threshold.
- History labels repeated any timeframe, but an unknown one falls back
to 24h and 7d/30d still cover only the 24 hours history is kept for;
describeHistoryWindow() says what the window really is.
- History trends, export analytics and optimize predictions come from
the analytics' own 24-hour history and are now labelled as such; the
export scope map lists only the sections it includes. History's scope
moves to data.scope {summary, trends}, like the alerts tool.
- wp_cache_stats / wp_cache_info show hit rates with one decimal, like
the performance tools ("16.7%", not "17%").
Co-Authored-By: Claude Opus 5.5 <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
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.
Pull Request
Description
Performance output polish from the v4.0.9 re-test results:
Alert messages printed raw floats:
High response time: 2096.285714285714ms.formattedMessagedid the same withactualValue.In the same minute the cache hit rate read 6.3% in stats, 2% in alerts and 16.7% for site1. Each figure has a different scope, and nothing said which:
Cache counters accumulate from server start; clearing entries doesn't reset them.
Type of Change
Changes Made
evaluateAlertConditions(): the response-time message is rounded to whole ms.actualValuekeeps the raw number.formatAlertMessage():actualValueandthresholdrounded to 2 decimals (2096.29,0.02)scopelabels:wp_performance_stats→cache("all sites combined, since the server started") andsiteSpecific("site site1 only, …");siteSpecific.cache.hitRateis now a percentage string like every other hit ratewp_performance_alerts→data.scope.alerts(recorded history: the value when each alert was raised) anddata.scope.activeAlerts(what is breaching now)wp_performance_history→summary.scope(average of N snapshots in the timeframe)wp_cache_stats→cache_stats.scope;wp_cache_info→current_stats.scope("this site only, since the server started")wp_performance_benchmark/wp_performance_optimizegetmetadata.scope;wp_performance_exportgets a scope map in its outermetadata(so CSV and summary carry it too);wp_performance_alertsgetsscope.anomalieswp_performance_historytotalRequestswas wrong: it summed cumulative totals across snapshots (100 + 150 + 230 = 480). It now reports the requests between the first and last snapshot (130), and the summary scope says each snapshot holds totals since the server started.src/performance/AGENTS.md: the three scopes, where each is reported, and the no-summing rule;docs/PERFORMANCE_MONITORING.md: a "Scope of the figures" section covering thesiteSpecific.cache.hitRatestringuptimewith epoch times). That is fixed in fix(performance): keep history snapshots by when they were taken #272, which merges cleanly with this PRtests/performance/OutputScope.test.js(14 tests). Intests/tools/cache.test.js, the two exact-shape assertions now includescope.Testing
format:check,security:scanwp_cache_stats,wp_performance_stats category=cache site=site1andwp_performance_alertseach returned theirscopetext.Notes for reviewers
scopefield in each response listed above, andsiteSpecific.cache.hitRatechanges from a 0–1 number to e.g."16.7%".Documentation
src/performance/AGENTS.md)Security
Independent review follow-up
formattedMessageno longer prints a breach as equal to its threshold. Rates keep 3 significant digits (1/19 →0.0526 vs 0.05), and more where needed (0.7996 vs 0.8).7d/30dcover the 24 hours history keeps (describeHistoryWindow()).data.scope {summary, trends}.wp_cache_stats/wp_cache_infoshow hit rates with one decimal, like the performance tools.totalRequests(last − first) needs fix(performance): keep history snapshots by when they were taken #272's deep-copied snapshots. Onmain, snapshots share the live counters, so the difference would always be 0. Verified on the combined build: 3 real snapshots of 100, 150 and 230 requests give 130.🤖 Generated with Claude Code
Summary by Sourcery
Clarify performance output scopes and improve alert and cache metric formatting while correcting historical request totals.
Bug Fixes:
Enhancements:
Documentation:
Tests: