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?).
- `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.
Wow! Thanks for the tips! Will look into adding those during the next review.
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.
I bought this exact model the other day, two days later it was cancelled and a refund was issued as they no longer had the 4K panel in stock. Looks like I'm going to miss out on these AMD CPUs this generation and have to go with an XPS 13 instead.
I am trying to order one. If I unselect Windows, I loose the 4K panel. If I go from 24G to 16G, I loose the 4K panel. If I go from 24G to 32G, I lose the 4K panel. And of course, delays are always 6+ weeks (which is Lenovo lingo to say "forever").
What a coincidence, just got off an over night Megabus one hour ago. However here in the UK they do not seem to have Wi-fi which is a great shame. Also they are normally very cramped here, so much so sometimes people are left to sit on the stairs whilst going down motorways or they call a bloke in a car to drive down the one or two extras ( which happened on my trip today ).
But in the end the price really does make up for it, and also each trip always has some weird goings on which is always fun. For example one trip there was a man who could not speak english at all who proceeded to drink himself stupid, get off at a random service station on the M6, fall asleep on a bench and refuse to come back on the bus. What a horrible morning he must have had.
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.