Modify scaling.md to no longer use pgbouncer environment wide, but only for Sidekiq

[smiba]

The current recommendation to run pgbouncer for the whole mastodon environment didn't sit entirely right with me.

This change in my opinion simplifies administration as it doesn't require the admin to take precaution with db:migrate, and keeps prepared_statements=true for mastodon-web.

Please let me know your opinion, and if changes are needed. This is just a quick writeup on what we're currently using over on our instance.

Of note:

• If the user has a different DB_HOST configured this will not connect to the local (pgbouncer) machine setup in the explanation, might be worthwhile including a DB_HOST env in the Sidekiq service file changes suggested, to make sure people are alert of this being relevant.
• If a replica is configured, setting DB_PORT causes an issue where sidekiq tries to also connect to the replica on this port. This is already an issue on the existing page, as it's not documented anywhere that sidekiq also makes use of the replica DB. (I remember this being explicitly not allowed in the past?) -- This can be resolved by also running an instance of pgbouncer on the replica on the same port though.

In general I believe these instructions should serve as an introduction for any admins, with further changes made to the configuration as they see fit for their setup.

[timetinytim]

Hmm this is a good point...

We use pgbouncer internally for our own instances, but these are relatively high-traffic instances that necessitate something like pgbouncer. For the average user, even up to a mid-traffic use case, it's probably not necessary just in general, considering the additional added complexity.

It might actually make sense for the documentation to not recommend pgbouncer in general, but rather have a section explaining the use case when you would need it (i.e. high traffic expectations), followed by the setup instructions and considerations.

Though I will defer to @renchap for goina head with a change like that.

[smiba]

I should by the way note that 95 threads used on the page really pushes sidekiq's max concurrency, and the master process may not be able to keep all threads occupied. (Even if there are tasks in the queue)
Past this number admins really should start looking into multiple sidekiq processes instead

We're running 4x50 at the moment, with 100 connections to the db host itself in pgbouncer (1:2 ratio), but I thought the scope and level of difficulty would be too big to suggest this to users right away

Would be happy to make the page a bit more in depth if this is something that is preferred though