FlowerDocs 2025.3 : Performance Benchmarks
Uxopian Software Engineering Team · 7 min read · Gatling Framework
At a glance : what the numbers say
FlowerDocs 2025.3 was tested under sustained load across six real-world document management scenarios. Here are the three numbers that matter most.
These figures were measured with 100 concurrent users over a sustained 10-minute window per scenario, run across all six scenarios back-to-back on the same platform instance, making memory leak detection possible alongside throughput measurement.
Architecture and test configuration
The test infrastructure runs on a 4-core pod configuration with Redis caching and OpenSearch indexing. Object storage relies on an S3-compatible layer. The Gatling load testing framework generates the traffic, and every result is compared against the previous release to catch regressions before they ship.
What we tested : six production scenarios
Each scenario reproduces an everyday workflow of a document management platform.
Results : raw benchmark data
| Scenario | Total requests | RPS | Min (ms) | Max (ms) | Mean (ms) | Std Dev | p50 | p75 | p95 | p99 |
|---|---|---|---|---|---|---|---|---|---|---|
| S1 | 1,844,641 | 3,069 | 11 | 3,757 | 32 | 16 | 31 | 36 | 50 | 63 |
| S2 ⚠ | 407,392 | 672 | 26 | 31,740 | 147 | 630 | 65 | 96 | 229 | 2,559 |
| S3 † | 3,524,496 | 5,864 | 4 | 843 | 17 | 7 | 8 | 10 | 14 | 18 |
| S4 † | 1,842,476 | 3,066 | 11 | 3,114 | 32 | 18 | 33 | 40 | 57 | 127 |
| S5 † | 187,072 | 311 | 12 | 2,027 | 320 | 227 | 481 | 646 | 943 | 1,183 |
| S6 | 45,147 | 75 | 250 | 4,031 | 1,329 | 537 | 1,239 | 1,702 | 2,316 | 2,652 |
⚠ S2 : isolated max outlier (31,740ms) reflects a single object storage timeout event under peak concurrent upload pressure.
Analysis : what the data tells us
The results reveal a robust infrastructure, supported by the 4-core-pod configuration and Redis, which handles pure metadata operations with remarkable efficiency.
Document reading dominates with 5,786 req/s and 17ms average latency, confirming the cache is working perfectly. Metadata creation and updates maintain high stability at around 30ms for approximately 3,000 req/s.
Document creation with content (S2) reveals an identified infrastructure constraint : under simultaneous large-file ingestion, throughput reduces to 122 req/s and max response time reaches 148.9 seconds, pointing to S3 storage layer pressure. FlowerDocs continued to handle requests correctly throughout.
Search at 1,143ms average on 1M+ documents remains acceptable, with OpenSearch and S3 identified as the primary bottleneck for complex operations.
What this means for you
- check Everyday operations are fast and reliable. Reading, creating metadata, and updating documents all respond under 50ms at the 95th percentile, across thousands of concurrent requests.
- check The caching layer works exactly as intended. Redis delivers sub-20ms average read latency at nearly 6,000 req/s, a clear validation of the architecture choices made in this release cycle.
- info Document creation with content : an identified infrastructure constraint. Under simultaneous large-file ingestion, response times are linked to S3 storage layer pressure, not to FlowerDocs itself.
- autorenew Continuous testing prevents regressions. Every version is benchmarked against the previous one, so past optimizations are never silently broken by new code.
Want to go deeper into the FlowerDocs architecture ?
Talk to our team about deployment configuration, sizing, and what these benchmarks mean for your specific usage volumes.