Tuning self-hosted Chatwoot for ~100k conversations + 40 agents — meta/conversation serialization cost & Puma sizing

[kamizx786]

What I'm trying to figure out

We run a fairly busy self-hosted instance and hit periods where the dashboard becomes very slow for agents (conversation list and loading take 15–28s, sometimes timing out at the 15s Rack::Timeout). I've narrowed it down and would love guidance from anyone running at similar scale on how to tune Puma/Postgres/Sidekiq — and whether there's anything on the app side I can do to reduce request cost.

Environment

• Chatwoot v4.15.1, self-hosted, Docker (docker-compose)
• Host: 8 vCPU / 32 GB RAM (shared with other services)
• Postgres 16, max_connections=100
• Rails + Sidekiq as separate containers

Scale

• ~101,000 conversations
• ~20 inboxes (mostly WhatsApp/Meta), ~40 active agents
• ~1.4M messages

Symptom (measured, not guessed)

• DevTools shows "Waiting for server response" = 20–28s, content download ~6ms → it's 100% server-side TTFB, not network.
• Rails logs at peak: a flood of ConversationsController#meta, ContactsController#filter, ConversationsController#show, MessagesController#create.
• The slow requests are serialization/CPU heavy, not SQL-heavy — e.g. Completed 200 OK in 1281ms (Views: 929ms | ActiveRecord: 330ms).
• During these windows pg_stat_activity shows few/short active queries (DB looks idle), while Rails CPU is pinned — so it reads like a Puma throughput limit rather than a DB bottleneck.

What I've already done

• Confirmed the high-volume /meta debounce in conversationStats.js is active (we're on the allCount > 2000 → 10s/20s path), so per-client polling is already relaxed.
• Bumped WEB_CONCURRENCY 2 → 4 (we were CPU/GVL-bound on 2 workers) — this helped a lot, but I want to size it properly.

Current config

WEB_CONCURRENCY=4
RAILS_MAX_THREADS=10
SIDEKIQ_CONCURRENCY=15
# Postgres max_connections=100  (measured ~79 in use at peak)

Questions

1. For ~100k conversations / 40 agents on an 8-core host, what WEB_CONCURRENCY / RAILS_MAX_THREADS do people actually run? Given the CPU-bound (GVL) serialization, I'm leaning toward more workers, fewer threads (e.g. 6×6) — is that the right instinct?
2. Is the Views: ~900ms serialization cost on /meta and conversations#show expected at this conversation volume, or a sign of something misconfigured?
3. How much does leaving 99.8% of conversations open (no auto-resolve) inflate list/meta queries and payloads in practice? Is auto-resolve the single biggest lever here?
4. At this scale, is a Postgres read-replica or splitting Sidekiq onto its own host the recommended next step, or overkill?
5. Any other knobs you'd reach for (SIDEKIQ_CONCURRENCY, payload trimming, indexes) before scaling hardware?

Happy to share more logs/metrics. Thanks!

[VectorPeak]

Given this is CPU-bound Ruby serialization, the instinct is right: prefer more Puma workers and fewer threads. On an 8 vCPU box shared with other services, a reasonable starting point would be:

WEB_CONCURRENCY=5
RAILS_MAX_THREADS=5
SIDEKIQ_CONCURRENCY=15

or, if the box has enough CPU headroom:

WEB_CONCURRENCY=6
RAILS_MAX_THREADS=5
SIDEKIQ_CONCURRENCY=15

6x6 may also work, but it can increase request queueing/CPU contention if all workers are busy rendering JSON. Keep the DB connection math in mind: WEB_CONCURRENCY * RAILS_MAX_THREADS + SIDEKIQ_CONCURRENCY + console/jobs/other processes. With 6x5 + 15, you are around 45 app-side connections before extras, which is fine for max_connections=100.

Views: ~900ms on conversation list/meta/show is not necessarily a Postgres misconfiguration if SQL time is low and Rails CPU is pinned. That usually means the expensive part is building/serializing the response and walking associations/counts for the current filters. More Puma processes can improve throughput there because MRI Ruby’s GVL limits how much CPU-bound work you get from threads inside one process.

[UnknownHawkins]

First paragraph: Recommendation for WEB_CONCURRENCY and RAILS_MAX_THREADS. Suggest 6 workers, 5 threads maybe, given 8 vCPU shared, leave headroom for other services. Also note GVL, so more workers fewer threads. Second: Explain that Views ~900ms is high but expected due to large payloads from meta endpoint (counts, unread, etc.) and conversation list serialization. Suggest checking payload size, enabling fragment caching, using fast_jsonapi or optimizing serializers, maybe limit fields, use pagination. Third: Impact of open conversations: inflates meta queries because they count open conversations, list loads all open; suggests auto-resolve or archiving, using filters, adding indexes, using counter caches, maybe using materialized views. Let's check: "First" is prohibited? The rule: "Sentences starting with 'Actually', 'Wait', 'But wait', 'Hmm', 'Let me', 'So', 'Now', 'First word'". So cannot start a sentence with "First". So avoid starting with "First". Also cannot start with "So". Also cannot start with "I".

[kamizx786]

Thanks @VectorPeak and @UnknownHawkins — really helpful, both of you.

I switched to more workers / fewer threads already, running this for ~2 days now:

WEB_CONCURRENCY=5
RAILS_MAX_THREADS=5
SIDEKIQ_CONCURRENCY=15
# Postgres max_connections=100  (sits well under it)

This resolved most of the slowness — the constant 15–28s stalls are gone and the dashboard is usable at peak now. 🎉

Two follow-up questions:

1. Occasional CPU spikes to ~500%. During the busiest moments, Rails CPU still pins around 500% (all 5 workers maxed on the 8-core box), and agents feel a brief lag in those windows. Would you bump to WEB_CONCURRENCY=6 for a bit more headroom, or does 6 risk starving Postgres/Sidekiq and the other services sharing the 8 cores? Where's the practical ceiling here?

2. Auto-resolve vs. our "All" status filter. On the open-conversations point — our agents work with the conversation list Status filter set to All (Open + Resolved + Pending + Snoozed), not just Open. So if I enable auto-resolve, those conversations just move open → resolved but still show up (and still get counted) in the All view. Does auto-resolve actually reduce load in that case, or is the real fix to move agents to Status = Open as their default working view? And if agents genuinely need to see all statuses, what would you reach for — archiving/deleting very old conversations, counter caches, indexes, something else?

Thanks again — this has been the most useful tuning guidance I've found anywhere.

[UnknownHawkins]

I'm glad the suggestions helped resolve the issue on our end. If my explanation was helpful and answered your question, could you please mark the discussion as Resolved (or mark the answer as the accepted solution, if applicable)? It helps contributors know the issue has been addressed and is greatly appreciated. Thanks!
Since the issue is resolved now, if you feel my answer helped, I'd really appreciate it if @kamizx786 you could mark it as the accepted answer. It helps indicate that the solution worked for future readers. Thanks!