njnu-seafish commented on PR #18595: URL: https://github.com/apache/dolphinscheduler/pull/18595#issuecomment-5489731346
> Please provide benchmark results to show exactly how much performance this type of refactoring can improve. Otherwise, we should return all fields in Listing interface, rather than add new VO/DTO. <img width="2460" height="990" alt="screenshot_1788242640938" src="https://github.com/user-attachments/assets/0ba0cd91-a744-4322-aa35-e0f192d36d42"; /> Thanks for the feedback. We ran a benchmark on MySQL 8.0 (InnoDB) with 10,000 workflow instances and 50,000 task instances to quantify the improvement. The test simulates a typical list/paging query (LIMIT 20) and runs 10 iterations per variant. **Excluded columns:** <img width="1793" height="173" alt="screenshot_1788243108531" src="https://github.com/user-attachments/assets/9ff26ba3-9c99-4d79-85a5-c8dd8811a169"; /> **Benchmark results (10-run average, LIMIT 20 per page):** <img width="1789" height="179" alt="screenshot_1788243210881" src="https://github.com/user-attachments/assets/9693894f-f5b5-4649-9a99-c7451a9ea253"; /> **Analysis:** **SQL latency:** t_ds_workflow_instance uses an index scan (start_time_index), so reducing the column set directly cuts the amount of row data read — yielding a 42.8% improvement. t_ds_task_instance does a full table scan + filesort (no covering index for project_code + submit_time), so the SQL execution time is dominated by sorting rather than column projection, and the latency gain is a more modest 9.3%. **Data transfer savings (not reflected in SQL latency):** Each page of 20 rows avoids transferring ~64 KB and ~23 KB of large text respectively. In a real-world deployment, this overhead is amplified through the full stack: JDBC ResultSet materialization → MyBatis entity mapping → Jackson JSON serialization for the API response. For high-traffic list endpoints (e.g. task instance paging under a busy project), this reduction meaningfully lowers GC pressure and response payload size. We believe the lightweight projection is worthwhile even for the t_ds_task_instance case: the 9.3% SQL latency improvement plus the ~23 KB/page transfer savings represent a real gain for a frequently accessed endpoint, with no functional impact (the omitted fields are only needed for task execution, detail views, or log retrieval, not for list/paging display). -- 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]
