What the data for this category looks like
The data for this category comes from customer color swatches, formula libraries, dye chemical batch records, dye vat control equipment, colorimeters, setting machines, and environmental monitoring devices. Daily generated documents include dyeing formulas, chemical dosing records, dye vat curves, proofing confirmation sheets, color difference reports, setting process sheets, sewage ledgers, and similar documents. Data update frequency is per vat, per batch, or per shift. Fields include dye vat temperature, chemical dosing ratio, color difference ΔE value, discharged COD value, etc., with corresponding units of ℃, g/L, no unit, mg/L, and others. Documents are primarily structured forms and unstructured time-series curves; the number of documents generated per single vat production fluctuates based on processing complexity.
What constraints these characteristics impose on deployment and upgrade
The characteristics of this category—high-frequency small-batch document updates, coexistence of unstructured time-series data and compliance documents—impose multiple constraints on deployment and upgrade. First, multiple documents generated per vat or batch will trigger sudden concurrent read/write requests, requiring stable database and storage performance. Second, unstructured time-series files such as dye vat curves have large file sizes, requiring configuration adapted to large-file upload and parsing. Third, compliance documents such as sewage ledgers require strict retention of original fields and metadata to avoid loss of critical information during parsing. Fourth, the characteristic of data fluctuating with production shifts requires the deployment environment to have elastic adjustment capabilities to adapt to resource demands across different time periods. During upgrades, interruption of document storage and calls related to production must be avoided, and configuration backups must be prepared in advance.
Configuration Settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
DB_MAX_LINK | 20–30 connections | This category generates multiple documents per vat or batch, with concurrent connection demand fluctuating with production shifts. This setting avoids connection pool exhaustion |
STORAGE_S3_ENDPOINT | Local object storage address, calibrated via actual testing | Unstructured files such as dyeing curves and color difference reports have large file sizes, requiring adaptation to local storage access configurations |
REDIS_URL | Local Redis service address, default port 6379 | Caches frequently called formula and color swatch data to reduce repeated query pressure on the database |
FILE_TOKEN_KEY | Randomly generated 32-bit string | Secures file upload interfaces to prevent unauthorized access to production-related dyeing and finishing documents |
MONGODB_URI | Configure replica set address, set connection timeout to 600 seconds | Stores large volumes of batched dyeing and finishing documents. Replica sets ensure data availability, and the timeout setting adapts to delays from large-file parsing |
Three Common Misconfigurations
- Container startup failure after upgrade: The symptom is a dependency version conflict error when running the docker compose up command. The cause is failing to overwrite existing configurations with the matching version configuration file, and failing to back up database configurations in advance.
- 413 error when uploading large files: The symptom is a 413 Request Entity Too Large response when uploading large files such as dye vat curves. The cause is failing to adjust the upload file size limit in the Docker deployment environment; the default limit cannot accommodate the size of dyeing and finishing documents.
- Empty result returned when calling the ollama model: The symptom is no valid response when sending a test call after configuring the ollama API address. The cause is the ollama service not opening local network ports, or the configured address not including the correct port number.
How to Confirm Successful Configuration
- Run the docker compose ps command to confirm that all FastGPT-related containers and dependent database and cache containers are in a running state.
- Upload a dye vat curve file of approximately 100 MB to confirm successful upload and that the parsed file can be viewed normally in the knowledge base.
- Configure the DeepSeek API key in the FastGPT v4.17.0 admin backend, send a test call, and confirm that normal model results are returned.
- View database connection logs to confirm that the current number of connections does not exceed the value set for
DB_MAX_LINK.
The values provided are common starting points and should be evaluated against the reader's own samples.