WeBlate UI preview endpoint and file watcher: Which is the primary bottleneck before optimization?

Direct answer

From the behavior you described, the UI preview endpoint is the more probable source of sustained CPU and I/O load. Because it retrieves all language files on every request, its cost scales with the number of projects and languages and is paid during ordinary browsing. The file watcher is more likely a freshness defect: missed rapid .po edits cause stale UI until refresh, but they consume little sustained CPU unless each miss triggers repeated repository rescans or queued update tasks.

This is a prioritized inference from your description, not a confirmed measurement. The confirmed facts are only that the preview endpoint reads all language files per request and that the watcher can miss rapid .po edits until a manual refresh.

Metrics that separate the components

Average latency hides the bottleneck. Compare percentiles and per-request resource counters, and scale project/language cardinality rather than only virtual users.

Signal	What it tells you
p50/p95/p99 latency and request rate	Whether previews degrade tail latency under realistic concurrency.
CPU time per preview request	Confirms parsing/rendering cost rather than background watcher cost.
Files opened and bytes read per request	Direct evidence of all-file retrieval.
Page-cache hit ratio and storage read latency	Distinguishes repeated disk I/O from cached work.
DB query count/time and Redis hit ratio	Shows whether previews bypass cache and add database load.
Celery queue depth and task duration	Reveals whether watcher misses cause update storms.

Read-only checks on a staging replica

pidstat -p $WEBLATE_PID 1
iostat -xz 1
redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys'

Use your Celery monitoring tooling to inspect active tasks and queue depth; exact commands vary by deployment.

Load scenarios that reveal the dominant cost

1. Idle baseline.
2. Steady multi-project browsing.
3. Preview-heavy traffic.
4. Cache-cold versus cache-warm previews.
5. Concurrent previews across many languages.
6. Mixed load with rapid edit bursts.

Detecting watcher misses

Use canary translations: write unique msgid/msgstr markers, poll the UI or API until visible, and record edit-to-visible latency and miss rate. Repeat with in-place writes and atomic rename/replace; editors often save by rename, which can evade simple watchers.

Prioritization rule

• If previews show high per-request file reads/parses and poor cache hit ratio, the preview path is the likely priority: cache rendered previews, reuse parsed catalogs, add pagination or lazy loading, and avoid all-file reads.
• If canary misses are frequent and cause repository rescans or Celery backlog, the watcher/update pipeline is the likely priority instead.

WeBlate version and configuration change exact route names and watcher behavior, so verify on your deployment before code changes.

One detail that changes the recommendation

Are preview responses cached per user/context, and what is the current cache hit ratio? If previews are already cached with a high hit ratio, the watcher-triggered update path is more likely to be the primary bottleneck.