|
|
|
|
|
|
by nigggle
1536 days ago
|
|
|
Baserow dev who worked on our new multi-container single image (baserow/baserow on dockerhub) here. I assume you are using the baserow/baserow image for pikapods (but perhaps not?). We have a few environment variables (https://baserow.io/docs/installation%2Fconfiguration) that can be tweaked for this image to make it start-up faster and with a lower resource footprint: - `SYNC_TEMPLATES_ON_STARTUP=false` to turn off the initial load of example Baserow templates. Our template collection is growing and the loading of this into the database is probably what is causing the several minute startup. This will be optimized in the future. - `BASEROW_RUN_MINIMAL=true`. This will combine two of the backend async queue processes into a single one. This might result into higher priority async tasks getting stuck behind slower tasks (an large import/export might slow down the broadcast of realtime events for example). But this tradeoff is perfectly reasonable in most small self hosted environments. - `BASEROW_AMOUNT_OF_GUNICORN_WORKERS=1` to reduce the number of concurrent backend api processes from the default of 3. Once again this might cause a degradation in performance for higher volumes of traffic, but a tradeoff worth considering if memory etc is a concern. This image is brand new and because of it's multi-process nature is hiding some interesting complexity. We are still working out the kinks and a sensible set of defaults. It's also very easy for us to offer different variants of this image with different defaults set. Any feedback, suggestions or questions are very welcome here or at http://community.baserow.io. |
|
|
Using docker.io/baserow/baserow:1.9.1 currently.
For now the image is marked as "experimental". And I'm looking into channeling future issue reports from apps in a more structured way and maybe keep app settings on Github for editing and reporting issues against. Without duplicating upstream efforts of course. Still lots of work to do here.