What the Data for This Category Looks Like
The data for this category mainly comes from engine Profiler tools, crash reporting platforms, real-device testing devices, and frame rate statistics tools. Daily produced documents include performance test reports, device adaptation lists, optimization records, and crash analysis reports. The update rhythm follows a daily or per-version iteration schedule. Data fields include frame rate values, package size, resource loading time, crash stack information, and more. Common units are fps, MB, and milliseconds. All data must be bound to corresponding device models and game version identifiers.
What Constraints Do These Characteristics Impose on Workflow Orchestration
The data sources for this category are scattered and have significant format differences. This requires the workflow to support connection to multiple types of data source nodes, and adapt to the output formats of different tools such as engine Profiler and crash platforms. The update frequency is daily or per version iteration, so the workflow must support binding version trigger or scheduled trigger nodes to align with project iteration rhythms. Daily produced document structures are inconsistent, so the workflow must support custom parsing templates to extract key information from performance test reports and optimization records. Core focus areas include specific indicators such as frame rate, package size, and resource loading, so the workflow must preset variables for corresponding fields and units. Errors in this process directly impact store reviews, so the workflow must configure abnormal alert nodes to notify relevant teams in a timely manner.
Configuration Settings
The following configurations are based on FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Data Source Access | Configure separate nodes for engine Profiler, crash platform, and real-device testing tools | Data sources for this category are scattered, requiring separate connection to output interfaces of different tools |
| Trigger Mode | 24 hours before version release, or 2:00 AM daily | Data update frequency is daily or per version, adapting to project iteration rhythms |
| Document Parsing Template | Preset constant fields for frame rate, package size, and resource loading time | This category focuses on the above indicators, requiring standardized extraction of key information |
| Timeout Retry Count | 3 times | The reproduction process for low-end devices takes a long time, requiring reasonable retries to avoid process interruptions |
| Abnormal Alert Trigger | Trigger when frame rate is below 30fps or package size exceeds 1000MB | Performance abnormalities directly cause stuttering, crashes, and affect store reviews |
| Variable Configuration | Bind device model and game version identifier, enable the variables parameter | Performance data must be bound to the corresponding environment to ensure accurate analysis |
| Node ID Configuration | Assign a unique nodeId to each workflow node | Facilitates troubleshooting of process abnormalities and quick location of problematic nodes |
Three Common Configuration Mistakes
- Phenomenon: The performance analysis results output after workflow execution do not include frame rate data. Cause: The extraction rule for the frame rate field is not bound in
variables, leading to the omission of core indicators during the parsing phase. - Phenomenon: The knowledge base search returns normal results, but the final judgment results do not reference the retrieved performance documents. Cause: No context association node is configured in the workflow, leading to the LLM not loading the knowledge base retrieval results when called.
- Phenomenon: No execution logs are generated after the workflow is triggered, and the node status shows that the configuration is not imported. Cause: The data source node and parsing node are not correctly associated, causing the process link to break.
How to Confirm the Configuration Is Properly Set Up
- The workflow's data source nodes are verified to confirm that the output interfaces of corresponding tools such as engine Profiler and crash platform have been connected.
- A test execution is triggered, and the parsed document is checked to confirm that core indicators such as frame rate and package size have been extracted.
- Scenarios where the frame rate is below 30fps or the package size exceeds 1000MB are simulated, and the abnormal alert node is confirmed to normally trigger notifications.
- The
variablesandnodeIdconfigurations are checked to confirm that the corresponding environment identifiers and unique node IDs have been bound.
The provided values are common starting points and should be measured against samples relevant to the specific deployment.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.