We just shipped a brand new container image that will be used on your next
./launcher rebuild app. As always, there is no need to change any configuration you have provided you followed our Discourse official Standard Installation. That said, there are new features that will help some installations out there.
We make heavy use of Redis in many places in Discourse, be it for cache, Sidekiq, MessageBus, Distributed Locks, Rate Limits All in all it’s been a rock solid choice for us.
However, at some very specific workloads, Redis could be a bottleneck. And because of Redis single threaded nature, coupled with our inability to use multiple instances due to our LUA scripts, it meant this was a hard bottleneck to workaround.
Thankfully, Redis 6 comes with support to using a thread pool for I/O operations, and during our tests it works very well with Discourse clusters bottlenecked by Redis.
So, if you are running on a machine with lots of CPU cores, and metrics showing Redis struggling to handle the load, you can now opt-in into using threads for writing operations via the app.yml params section:
params: redis_io_threads: "4" # 1 disables it, n>1 uses n-1 extra threads for IO writes
We opted to ship a large container image early on in the project, so we can make it easier for non-technical people to run Discourse, and handle all necessary dependencies, versioning, upgrades, etc.
That said, we recently went over 1GB for the compressed image, and that was a bit too much.
So in order to mitigate the ever increasing size of the image, we moved the Discourse source code from inside the image from a complete copy of the source code to a “shallow clone” containing only the most recent version of the code.
This changes makes the compressed image size 25% smaller, which results in less server space needed and faster rebuilds when a new image is released. It also should control the image growth over time.
We tested it on tests-passed/beta/stable, with both rebuilds and web updates and it doesn’t break any standard paths. However, users doing more exotic git stuff on the app.yml hooks may have to adapt their customizations.