BaryoDev / BaryoDev/barakoCMS

Lighter and faster: measured tuning for Postgres, the API image and hot queries

Open
#798 1 comment 0 reactions 0 assignees View on GitHub
epic performance
Dominant language
C#
Stars
6
Forks
7
Avg merge
4h 42m
Merged PRs (30d)
307

Description

One API and one barakoPress now serve several sites on a 2 GB VM (#722), so memory, startup and per-request cost matter more than they did. Every step below is kept only if it beats a measured baseline. No tuning by guesswork.

## Where it stands, measured on 14 September 2026

- **Memory at rest** on barakocms.com: API 186 MB, console 53 MB, site 120 MB, Postgres 31 MB, about 390 MB total.
- **Public delivery** answers in about 10 to 20 ms (`GET /api/public/post` in the API log). **Startup** takes about 3 seconds, most of it the module schema checks.
- **Postgres runs stock:** `shared_buffers` 128 MB, `random_page_cost` 4 (a spinning-disk assumption), `jit` on (adds planning time to small web queries), `work_mem` 4 MB, and no `pg_stat_statements`, so slow queries cannot be found.
- **The API image** is a plain `dotnet publish`: no ReadyToRun. Server GC with DATAS, the .NET 10 default, already adapts heap size to load.
- **Marten 9** no longer generates code at runtime, so there is no pre-generation step to add. No compiled queries are used; the delivery list builds its filters with `MatchesSql` at runtime, so it is not a compiled query candidate.

## Steps

- [ ] **1 and 2. Baseline and Postgres settings for small servers.** Moved to 4.2.0 as #799, so the first configured site starts tuned. Its numbers are recorded here.
- [ ] **3. ReadyToRun in the API images.** `PublishReadyToRun` in `Dockerfile` and `Dockerfile.suite`. Kept only if startup and first-request latency improve enough to justify assemblies two to three times larger.
- [ ] **4. Compiled queries for fixed-shape hot reads**, through `Marten.SourceGenerator` and `[assembly: JasperFx.JasperFxAssembly]`: tenant by slug, content type by name, entry by slug, membership roles, token issuing, API key lookup. Measure per-call time before and after.
- [ ] **5. Caching that already has issues:** one round trip for count and page (#508), ETag and 304 (#549), purge on publish instead of a 60 second window (#561). With barakoPress's per-tenant cache (BaryoDev/barakoPress#20), most reads should never reach Postgres.

## Not now

- **Native AOT.** Modules are discovered at runtime and FastEndpoints and Marten LINQ lean on reflection, so it is a large project for a modest memory win. Revisit after steps 1 to 5 with numbers.
- **Changing GC mode or trimming globalization** without a measurement. The defaults already adapt, and invariant globalization could quietly change date formatting.

## Done when

- The baseline and the after numbers for each kept step are recorded in this issue.
- A step that did not improve its number is reverted and noted here as tried.

Contributor guide

Open the contributing guide

Research direction

Start with the measured baseline in this issue, then inspect Dockerfile and Dockerfile.suite for the ReadyToRun change. Review the listed Marten.SourceGenerator query candidates and the caching issues before choosing a step. Done means recording before-and-after numbers for each retained step, and reverting and noting any step that does not improve its measure.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp, docker, postgresql
Domain
backend-api-design, databases, devops, performance
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.