Performance and slowness

SummitPSA runs as a small Docker Compose stack: a MariaDB database container and the app container (Gunicorn serving Uvicorn workers). Slowness almost always traces to one of those two or to the host.

Check the basics first

From the install directory, confirm both containers are healthy and watch resource use:

cd /opt/summitpsa
docker compose ps
docker stats

A database container stuck unhealthy, or a host pinned at 100% CPU or out of memory, explains most stalls.

Tune web workers

The app serves requests with Gunicorn using 3 Uvicorn workers by default. On a busier install with spare CPU and RAM, raise this with the WEB_CONCURRENCY environment variable in .env.docker, then recreate the app container. The per-request timeout is 120 seconds; requests exceeding that are killed.

Database

All application data except uploaded files lives in MariaDB. If queries feel slow, check the DB container's memory and disk, and confirm the db_data volume's underlying disk isn't full or heavily contended. Migrations run automatically on every boot (alembic upgrade head); a very large pending migration can make the first start after an upgrade slow — that's expected and one-time.

Email polling overhead

Inbound IMAP polling runs on a schedule against every active account that has IMAP configured. A large unread backlog, or an account whose server is slow to respond, can add load each cycle. Clearing backlogs and removing dead accounts helps.

Where to look

The app logs to stdout/stderr, captured by Docker:

docker compose logs -f app
docker compose logs -f db

Look for slow-request warnings, worker timeouts, or repeated database connection retries.