Performance and reliability

Separate the symptoms

Measure request latency, errors, CPU, memory, disk capacity and database behavior. Separate slow listing from slow file transfer, provider latency and proxy interruptions. Compare like-for-like datasets and record the exact build. The docs provide no general performance promise or benchmark claim.

Use bounded requests

Paginate large lists instead of asking for an entire account at once. Avoid uncontrolled parallel attachment uploads or transcription calls. Temporary database pressure can produce an unavailable error; use bounded backoff for safe reads, and inspect state before retrying non-idempotent writes. Keep rate limiting on unless you have a justified, separately reviewed reason to change it.

Streaming and storage

The HTTP/1.1 listener applies a 15-second header-read timeout, including idle keep-alive connections; clients must reconnect after an idle close. General bodies and streams do not share that header deadline. Check proxy idle/buffering policies separately. Local and S3 attachment bytes can stream, while database BLOB storage is buffered, which affects memory planning.

Capture a small read-only baseline

Run the following against the same instance before and after a change. The health latency isolates a cheap request, not realistic memo-query performance. Pair it with one fixed read-only list request using the same account, filters and page size. Record timestamp and build identity. Container memory or disk pressure alongside rising request latency is evidence to investigate, not proof of which subsystem caused it.

date -u
curl --silent --show-error --output /dev/null \
  --write-out 'status=%{http_code} connect=%{time_connect}s total=%{time_total}s\n'   http://127.0.0.1:5230/healthz
docker stats --no-stream memos
docker exec memos df -h /var/opt/memos
docker logs --since 10m --tail 100 memos