-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collect request stats #9633
Collect request stats #9633
Changes from 5 commits
60a99fb
2616b83
0fcff55
adda334
d97c10f
82388b7
797e11d
3086ef2
06a50e3
3277f54
170f528
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1027,6 +1027,7 @@ export default class RequestTracker { | |
farm: WorkerFarm; | ||
options: ParcelOptions; | ||
signal: ?AbortSignal; | ||
stats: Map<RequestType, number> = new Map(); | ||
|
||
constructor({ | ||
graph, | ||
|
@@ -1205,6 +1206,9 @@ export default class RequestTracker { | |
|
||
try { | ||
let node = this.graph.getRequestNode(requestNodeId); | ||
|
||
this.stats.set(request.type, (this.stats.get(request.type) ?? 0) + 1); | ||
|
||
let result = await request.run({ | ||
input: request.input, | ||
api, | ||
|
@@ -1227,6 +1231,36 @@ export default class RequestTracker { | |
} | ||
} | ||
|
||
flushStats() { | ||
let requestTypeEntries = {}; | ||
type RequestTypes = Array<$Keys<typeof requestTypes>>; | ||
|
||
for (let key of (Object.keys(requestTypes): RequestTypes)) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. /nit you could just create this mapping at the top of the file so it's done once, and it could be more idiomatic using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. True about top of the file. However we used keys because the flow types to get entries happy was super ugly. |
||
requestTypeEntries[requestTypes[key]] = key; | ||
} | ||
|
||
let formattedStats = {}; | ||
let messageLines = ['Request stats']; | ||
|
||
for (let [requestType, count] of this.stats.entries()) { | ||
let requestTypeName = requestTypeEntries[requestType]; | ||
formattedStats[requestTypeName] = count; | ||
messageLines.push(`${requestTypeName}\t\t${count}`); | ||
} | ||
|
||
let message = messageLines.join('\n'); | ||
|
||
logger.verbose({ | ||
origin: '@parcel/core', | ||
message, | ||
meta: { | ||
requestStats: formattedStats, | ||
benjervis marked this conversation as resolved.
Show resolved
Hide resolved
|
||
}, | ||
}); | ||
|
||
this.stats = new Map(); | ||
} | ||
|
||
createAPI<TResult>( | ||
requestId: NodeId, | ||
previousInvalidations: Array<RequestInvalidation>, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if we want to go down this rabbit hole, but it's pretty common for success events to store stats regarding the build. Instead of having
flushStats
, you could add the stats directly to build success under a new key and then get the reporter to log it.That way the
RequestTracker
does not have to care about how to report the info, it just gives it to whatever wants to consume it. This is similar to what @marcins noted before, but can be extended to other stats we want to measure.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree this would be nicer. We opted not to do it that way to avoid adding Parcel public API that would be a breaking change to remove or modify in future. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As an aside, I'm looking at adding high-level (and potentially more granular) perf metrics and am starting to explore options. Having a stats object or something similar to that would be useful.
In regards to the public API, you could name the field as
unstable_stats
to make no guarantees to consumers. Or in a similar fashion, expose that there is a stats object but type it as a record with any value. That way, we are saying we will provide it but make no guarantees about what's in there. We'd probably need something internal to give us types we know about to make logs or w/e on them, but it doesn't need to be exposed.