Quality Problem Traceability and Defect Analysis for Rubber Mixing and Product Vulcanization: Deployment and Upgrade

Data for this category comes from formula management systems, raw material batch ledgers, internal mixer operation logs, Mooney viscosity and

What data looks like for this category

Data for this category comes from formula management systems, raw material batch ledgers, internal mixer operation logs, Mooney viscosity and rheometer test data, vulcanizer process records, and laboratory finished product performance reports. Daily documents include formula sheets, weighing and feeding records, mixing temperature-time curves, rapid rubber compound test results, vulcanization process cards, mold usage records, and performance reports including finished product tensile strength, among others. Data updates follow the cadence of per raw material batch per truck, per mixed rubber batch, and per vulcanized product per mold cycle. Data fields include batch numbers, process parameter values, test results, operator identifiers, and similar items.

Constraints imposed during deployment and upgrade

This category has high-frequency, closely linked data updates. Deployments must support high-concurrency bulk data writes to avoid single-batch data backlogs. Multi-source heterogeneous data formats require deployment configurations to support unified storage of structured process parameters, unstructured curves, and report files. Since mixing and vulcanization processes are irreversible, data must be guaranteed to be immutable after writing. Therefore, database configurations must enable transactional writes and immutable storage policies. The requirement for multi-device docking means the deployment architecture must support lightweight data synchronization across multiple endpoints to prevent full-process data collection from being impacted by single-point failures.

Configuration settings

These settings apply to FastGPT v4.17.0.

Configuration ItemRecommended SettingRationale
MONGODB_URISet to a replica set connection string, with the connection pool size set to 200 connectionsThis category has frequent data updates and includes unstructured files. MongoDB supports storage of multiple data types, and a large connection pool can support high-concurrency writes
REDIS_URLConfigure an instance with no less than 1000 MB of memory, set the maximum memory usage limit to 1200 MB, and enable RDB persistenceUsed to cache frequently accessed process parameters and batch indexes. Persistence prevents cache loss after restart, which would impact data association queries
STORAGE_S3_ENDPOINTConfigure an object storage endpoint suitable for large file storageUsed to store large documents such as mixing curves and performance reports, meeting bandwidth requirements for multi-device uploads
DB_MAX_LINKSet to 150–250 connectionsMatches database connection requirements for multi-device concurrent access, preventing data write failures caused by exhausted connections
FE_DOMAINConfigure a full protocol-inclusive domain name, such as https://fastgpt.example.comUsed for front-end page resource loading and interface calls, adapting to intranet and extranet deployment scenarios
FILE_TOKEN_KEYSet based on actual measurementUsed to generate file access tokens, must match the signature verification rules of the object storage

Three common configuration mistakes

  • Symptom: A "database connection timeout" error appears during container deployment, with logs showing connection pool exhaustion. Cause: The value range of DB_MAX_LINK was not configured correctly, leading to insufficient database connections during high-concurrency data writes.
  • Symptom: iOS devices display a blank screen when accessing the deployed page, while macOS and Windows devices function normally. Cause: FE_DOMAIN was not correctly configured as a full protocol-inclusive domain name, leading to cross-origin resource loading failures.
  • Symptom: GPU utilization is low after connecting to a large model, while single-core CPU occupancy remains high. Cause: The data loading batch size was not adjusted, leading to frequent model calls triggered by small batches of data, failing to fully utilize GPU computing power.

How to verify a successful configuration

  • Run the database connection test script to verify the connectivity of MONGODB_URI and REDIS_URL, and check whether the connection pool usage is within the range acceptable for the business.
  • Upload a mixing curve PDF file, confirm that the file can be uploaded and downloaded normally through the storage service corresponding to STORAGE_S3_ENDPOINT, and that the access link opens normally.
  • After configuring FE_DOMAIN, access the front-end page from different terminal devices to verify that there are no abnormal errors in resource loading and interface calls.
  • Simulate a single-batch mixed data write process, and check whether the database write delay meets business requirements.

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