haiyangsun-db commented on code in PR #59111:
URL: https://github.com/apache/spark/pull/59111#discussion_r4146352881
##########
udf/worker/proto/src/main/protobuf/org/apache/spark/udf/worker/udf_message.proto:
##########
@@ -482,6 +479,55 @@ message CancelResponse {
optional ExecutionError error = 2;
}
+// Per-execution metrics accumulated by one Execute stream, as measured by the
+// worker. Each field is cumulative for the stream. Absence means unavailable;
+// zero means measured zero. "In" counts data the worker received from the
+// engine and "out" counts data it returned. Byte counts are data payload
+// bytes and exclude gRPC, HTTP/2, and TLS framing. Timing values are
+// nanoseconds; the wait times [[receive_wall_nanos]] and [[send_wall_nanos]]
+// are not transfer times and MUST NOT be used as rate denominators.
+message ExecutionMetrics {
+ // Bytes of [[DataRequest.data]] payload received.
+ optional uint64 bytes_in = 1;
+
+ // Bytes of [[DataResponse.data]] payload returned.
+ optional uint64 bytes_out = 2;
+
+ // Rows in the received data payloads. Absent unless the rows of every
+ // received payload could be counted.
+ optional uint64 rows_in = 3;
+
+ // Rows in the returned data payloads. Absent unless the rows of every
+ // returned payload could be counted.
+ optional uint64 rows_out = 4;
+
+ // Number of [[DataRequest]] messages received.
+ optional uint64 batches_in = 5;
+
+ // Number of [[DataResponse]] messages returned.
+ optional uint64 batches_out = 6;
Review Comment:
would it make sense to track max batch size?
##########
udf/worker/proto/src/main/protobuf/org/apache/spark/udf/worker/udf_message.proto:
##########
@@ -482,6 +479,55 @@ message CancelResponse {
optional ExecutionError error = 2;
}
+// Per-execution metrics accumulated by one Execute stream, as measured by the
+// worker. Each field is cumulative for the stream. Absence means unavailable;
+// zero means measured zero. "In" counts data the worker received from the
+// engine and "out" counts data it returned. Byte counts are data payload
+// bytes and exclude gRPC, HTTP/2, and TLS framing. Timing values are
+// nanoseconds; the wait times [[receive_wall_nanos]] and [[send_wall_nanos]]
+// are not transfer times and MUST NOT be used as rate denominators.
+message ExecutionMetrics {
+ // Bytes of [[DataRequest.data]] payload received.
+ optional uint64 bytes_in = 1;
+
+ // Bytes of [[DataResponse.data]] payload returned.
+ optional uint64 bytes_out = 2;
+
+ // Rows in the received data payloads. Absent unless the rows of every
+ // received payload could be counted.
+ optional uint64 rows_in = 3;
+
+ // Rows in the returned data payloads. Absent unless the rows of every
+ // returned payload could be counted.
+ optional uint64 rows_out = 4;
+
+ // Number of [[DataRequest]] messages received.
+ optional uint64 batches_in = 5;
+
+ // Number of [[DataResponse]] messages returned.
+ optional uint64 batches_out = 6;
+
+ // Wall time spent handling [[Init]] before sending [[InitResponse]].
+ optional uint64 init_wall_nanos = 7;
+
+ // Wall time from sending [[InitResponse]] until the stream's first
+ // terminal event: finish, cancellation, or an execution error.
+ optional uint64 processing_wall_nanos = 8;
Review Comment:
Something not very generic, but could be helpful is the first result batch
sent wall time since processing starts, that could somehow indicate the latency
of the processing. In a good streaming-style execution, the first batch could
be streamed soon for lower latency.
But this is not a very standard metric, we can also add later if you prefer.
##########
udf/worker/proto/src/main/protobuf/org/apache/spark/udf/worker/udf_message.proto:
##########
@@ -482,6 +479,55 @@ message CancelResponse {
optional ExecutionError error = 2;
}
+// Per-execution metrics accumulated by one Execute stream, as measured by the
+// worker. Each field is cumulative for the stream. Absence means unavailable;
+// zero means measured zero. "In" counts data the worker received from the
+// engine and "out" counts data it returned. Byte counts are data payload
+// bytes and exclude gRPC, HTTP/2, and TLS framing. Timing values are
+// nanoseconds; the wait times [[receive_wall_nanos]] and [[send_wall_nanos]]
+// are not transfer times and MUST NOT be used as rate denominators.
+message ExecutionMetrics {
+ // Bytes of [[DataRequest.data]] payload received.
+ optional uint64 bytes_in = 1;
+
+ // Bytes of [[DataResponse.data]] payload returned.
+ optional uint64 bytes_out = 2;
+
+ // Rows in the received data payloads. Absent unless the rows of every
+ // received payload could be counted.
+ optional uint64 rows_in = 3;
+
+ // Rows in the returned data payloads. Absent unless the rows of every
+ // returned payload could be counted.
+ optional uint64 rows_out = 4;
+
+ // Number of [[DataRequest]] messages received.
+ optional uint64 batches_in = 5;
+
+ // Number of [[DataResponse]] messages returned.
+ optional uint64 batches_out = 6;
+
+ // Wall time spent handling [[Init]] before sending [[InitResponse]].
+ optional uint64 init_wall_nanos = 7;
+
+ // Wall time from sending [[InitResponse]] until the stream's first
+ // terminal event: finish, cancellation, or an execution error.
+ optional uint64 processing_wall_nanos = 8;
+
+ // Wall time spent waiting for the next request from the engine.
+ optional uint64 receive_wall_nanos = 9;
+
+ // Wall time spent blocked sending responses to the engine.
+ optional uint64 send_wall_nanos = 10;
+
+ // Wall time spent executing received data: decoding input, running the
+ // UDF, and encoding output. Excludes the wait times.
+ optional uint64 work_wall_nanos = 11;
+
+ // CPU time consumed executing received data.
+ optional uint64 work_cpu_nanos = 12;
Review Comment:
There is also a wall time between last result batch sent - the data
processing phase ends, and finish response sent.
Usually in spark udf case, the data processing ends would already trigger
task completes, while the finish response is handled in the task completion
listener.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
