ansible-discourse is an Ansible playbook I created to easily deploy Discourse without Docker. It supports several distributions, including CentOS, Debian, Fedora and Ubuntu. This installation method is completely unsupported so please don’t post issues to meta.discourse.org. Instead, open a topic here.
From a very particular way of running unicorn (so it forks out sidekiq) to jemalloc, out-of-band gc and gc tuning.
The Ruby 2.2 image we have (which is enabled on meta) is a custom build of Ruby with method cache patches. Unfortunately, even patched we are struggling to meet the same memory and cpu perf we get on 2.0, hence it is not yet default.
Ah ok, when codinghorror said “Linux tuning” I assumed he meant Linux kernel tuning . I agree there is plenty of tuning of other components and my aim was to replicate all of this tuning. (Though in fact, ansible-discourse does some kernel tuning too.)
ansible-discourse should also be doing all of these things. Tuning is done for Ruby/Unicorn (environment variables, jemalloc, workers etc), Redis (kernel tuning), PostgreSQL (shared_buffers, work_mem etc) and NGINX (workers, ratelimiting, spdy etc).
I’ve defaulted to Ruby 2.2 as I was under the impression everything was fine . Perhaps I’ll drop back to Ruby 2.0.
As you yourself noted, you were not aware Ruby 2.2 is a big performance regression. Nor did you know about the patches we use for Ruby 2.0. This is all fine, but you’re forking the install, and you will never know as much about Discourse performance as we on the Discourse team do.
Which is why people should stay on the Docker install, which always automatically reflects optimal Discourse settings, unless someone is basically holding a and forcing them not to use Docker.
You also lose the one-click web updater, of course.
edit: I don’t mean to sound negative, because I appreciate your hard work, but there is a reason we ask everyone to use the Docker based install, and it’s the only one we can support.
The public Discourse Docker image doesn’t contain any Ruby 2.0 patches as far as I can see.
Very true. But I won’t ever need to know as much because all of the optimizations in the public Discourse Docker image are public and can therefore be replicated.
Sure, for high-traffic sites with a need for guaranteed uptime etc, you need either a lot of in-house experience or to purchase premium support from Discourse. I’ve made it clear that this is unsupported, and I even encourage premium support in the README, so I’m definitely not trying to compete here! I’m really just sharing something that was originally just for private use, because there may be some people that find it useful.
We don’t have the employees or bandwidth to support multiple methods. All our wood goes behind one arrowhead – the Docker install, which we use everywhere, internally and externally, and that’s the only form of install we support.