mfrancisc opened a new issue, #9058: URL: https://github.com/apache/devlake/issues/9058
We are sizing a DevLake deployment for a large GitLab estate and want to know whether a single instance is expected to handle this, and how we should configure projects/blueprints if so. **Scale** - One product org already has ~6,500 GitLab repos; we need to plan for tens of thousands across the company. - Teams are disjoint (no shared repos between team projects). - We still need org- and company-wide metrics (e.g. Cycle Time) from one database. We do not use Grafana; a metrics API reads the same MySQL. - Splitting into isolated DevLake+MySQL stacks would speed collection, but then we could not compute org- or company-wide Cycle Time with a single query against one database. _What we think is the intended setup (please correct us)_ : - One lake process, one MySQL (we know a second instance on the same DB_URL hits the exclusive _devlake_locking_stub lock). - Many team-sized projects/blueprints (tens to ~150 repos each), not one project with 6,500 scopes. - PIPELINE_MAX_PARALLEL > 1, staggered crons, incremental sync, skip heavy gitextractor options if needed. **Questions** 1. Has anyone run DevLake successfully at a few thousand GitLab repos on one instance? What project size, PIPELINE_MAX_PARALLEL, and sync policy actually worked? 2. Is the guidance above right, or is there a better project/blueprint layout for this? 3. At this scale, is the bottleneck expected to be the single runner (sequential blueprints / sequential GitLab stages) rather than MySQL? 4. If one instance cannot keep a daily incremental cycle, is the intended path still “more hardware on one process”, or is multi-instance sharing one DB something the project would consider? Related: #8448, #8802, #8260 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
