Jinkō platform known limitations
Performance and scalability by design
Jinkō is designed to be a fast, robust, and scalable solution, aimed at revolutionizing how simulations in drug development are conducted. Just like how a Formula 1 car, built for speed and agility on the racetrack, isn't suited to hauling heavy payloads, and a lorry, designed for carrying heavy loads, wouldn't perform well in a high-speed race, Jinkō has its operational limits. These limits, akin to the soft boundaries on a racetrack, guide users on how best to utilize the platform to achieve optimal performance without compromising the overall system integrity.
While Jinkō encourages exploration beyond these boundaries, it's crucial for users to understand that doing so is at their own risk. Should their simulation demands excessively strain the platform, potentially degrading the experience for others, we reserve the right to intervene by canceling the simulation.
The outlined limits span various Project Item types, from the number of components in a Computational Model to the size and number of Protocol Arms, Trials, Trial Visualizations, Documents, Bibliographic references, and overall Project Items. These guidelines are established to maintain Jinkō's high performance and reliability while accommodating the diverse needs of our users, ensuring that Jinkō remains a cutting-edge platform for simulation in drug development.
The limits
| Project Item (PI) type | Limit type | Soft limits | Rationale |
|---|---|---|---|
| Computational Model | Number of components | 5,000 | Edit is slow for very large (10k+ components) models and graph lags for medium size (1k +) models when depth ≥ 3 |
| Virtual Population | Size = Number of descriptors x Number of patients | 1,000,000 | Size of uploaded file (stream) |
| Protocol Arms | Number of arms | 100 | Trial monitoring needs to be improved both in core and front to account for a large arm set |
| Protocol Arms | Number of descriptors | 1,000 | Display in the front (no pagination or lazy loading for now) |
| Trial | Size = Number of patients x number of arms | 100,000 | The limits are the trial monitoring and the download of results for now, notably if the user selects too many descriptors |
| Trial Viz | Time Series Aggregate (num patients) | 1,000 | The time series aggregate does not work well beyond 1000 patients |
| Document | Numbers of words | 500,000 | Limit is more on the client side and can vary from one user set-up to another, this holds for a machine with 16Gb of RAM and 4 CPUs |
| Document | Number of Cm renderers / equations | 200 | Limit is more on the client side and can vary from one user set-up to another, this holds for a machine with 16Gb of RAM and 4 CPUs |
| Bibliographic reference | Scientific article max size | 50MB | Rendering / Knowledge processing |
| All PIs | Max PI count per project | 10,000 | Maintenance, navigability,Re-use (project carbon copy),Back-up |
| All PIs | File size upload | 2GB | Network, backup & maintenance (hard limit on backend is 15GB because of large json vpops) |
| All PIs | Max number of users editing the same PI at the same time | 10 |
