consider more unicorn workers

[vmpjdc]

Enhancement Proposal

We've found that some of our busier Discourse deployments need quite a few Juju units to keep up with the traffic.

The charm starts 3 unicorn workers, and since unicorn also needs to be able to respond to pebble checks, each unit on average can handle a little under 3 concurrent user requests. Every unit also runs a few other things (sidekiq, monitoring, etc.) and this fixed overhead adds up.

It would be nice if each unit started more unicorn workers, although since it seems the guidance (for example) generally boils down to:

1. no more than 2 workers per real CPU core; and
2. as many workers as you need,

perhaps this is one of the rare cases where a charm setting makes sense.

[cbartz]

@nrobinaubertin Can you please check if this is possible and create a jira ticket if possible?

[nrobinaubertin]

I moved the automatically created ticket to the right place (ISD-2580).

For future reference:

The number of workers is controlled by the following line in /srv/discourse/app/config/unicorn.conf.rb in the container:

worker_processes (ENV["UNICORN_WORKERS"] || 3).to_i

The best is probably to add a parameter here: https://github.com/canonical/discourse-k8s-operator/blob/main/src/charm.py#L416

[yanksyoon]

Adding reference link to ISD-2580 for future ninjas.