Release Notes and Operations Report Summary for Game Client Performance Optimization: Database and Operations

Data for this category comes from Engine Profiler, crash platforms, real device testing tools, and frame rate collection systems. Updates occur daily

What this category’s data looks like

Data for this category comes from Engine Profiler, crash platforms, real device testing tools, and frame rate collection systems. Updates occur daily or per version iteration. Daily output documents include performance test reports, device adaptation lists, optimization records, and crash analysis reports. Data fields cover frame rate values, resource usage, crash log entries, and test device identifiers. All documents are linked via test batch IDs. The core focus is client runtime performance and adaptation status.

What constraints these characteristics impose on database and operations

This category’s data is multi-source and updates frequently. It also requires cross-document linked queries. These impose multiple constraints on database and operations workflows. Multi-data source writing requires support for batch concurrent write operations to avoid data backlogs. High-frequency updates and large-volume performance data require databases with sufficient storage capacity and read/write performance to support full data synchronization daily or per version. Data queries linked by test batch, device, and version require databases to support flexible partitioning and index configuration. This ensures linked query response speed matches the pace of performance optimization iterations. Additionally, unstructured crash logs and structured test reports need storage configurations tailored to the characteristics of different databases.

How to set configurations

Configuration ItemRecommended ConfigurationRationale
MONGODB_URImongodb://user:pass@host:27017/dbname?maxPoolSize=50&w=1Adapts to storage and query of unstructured crash logs and raw Engine Profiler data. Configures connection pool size to support concurrent test tasks, and aligns with FastGPT v4.17.0 multi-data source storage logic
PG_URLpostgresql://user:pass@host:5432/dbname?sslmode=requireStores structured performance test reports and device adaptation lists. Supports complex linked queries and version partitioning, meeting structured storage requirements for game client performance data
DB_MAX_LINK200–300Balances database connection resources and concurrent write requirements. Adapts to daily multi-batch performance data synchronization tasks, and prevents service interruptions caused by exhausted connections
REDIS_URLredis://:pass@host:6379/0Caches popular device adaptation data and recent frame rate statistics. Reduces repeated query pressure on databases, and improves linked query response speed

Three common misconfigurations

  • Symptom: Interface call restricted errors occur when concurrently submitting multiple batches of performance test data. Cause: DB_MAX_LINK parameter is not set reasonably. The database connection pool cannot support concurrent writes from multiple tasks. This leads to service exceptions under concurrent business pressure.
  • Symptom: Linked frame rate queries that include device and version information respond slowly. Cause: No indexes are created on the test batch ID and device fields of the PostgreSQL database. This causes full table scans, and cannot support multiple rounds of query demands for problem optimization.
  • Symptom: Partial loss of crash logs stored in MongoDB. Cause: Write confirmation parameters are not configured. This causes partial data to fail to persist to disk during batch writes, affecting the completeness of crash analysis.

How to confirm correct configuration

  • Run batch performance data write scripts, monitor database connection usage, and confirm that connection count does not exceed the configured DB_MAX_LINK threshold.
  • Execute cross-document linked queries, verify that query response speed meets the time requirements of business iterations. Adjust index configurations based on actual scenarios.
  • View Redis cache access logs, confirm cache hit rates for popular device adaptation data. Adjust cache expiration rules based on business access frequency.
  • Randomly sample written crash logs and test report data, verify normal query and linking capabilities, and confirm that data persistence is effective.

The values given are common starting points and should be measured against the reader's own samples.

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.