Heyho,

as a PostgreSQL guy, i’m currently working an tooling environment to simulate load on a lemmy instance and measure the database usage.

The tooling is written in Go (just because it is easy to write parallel load generators with it) and i’m using tools like PoWA to have a deep look at what happens on the database.

Currently, i have some troubles with lemmy itself, that make it hard to realy stress the database. For example the worker pool is far to small to bring the database near any real performance bootlenecks. Also, Ratelimiting per IP is an issue.

I though about ignoring the reverse proxy in front of the lemmy API and just spoof Forwarded-For headers to work around it.

Any ideas are welcome. Anyone willing to help is welcome.

Goals if this should be:

  • Get a good feeling for the current database usage of lemmy
  • Optimize Statements and DB Layout
  • Find possible improvements by caching

As your loved core devs for lemmy have large Issue Tracker backlog, some folks that talk rust fluently would be great, so we can work on this dedicated topic and provide finished PR’s

Greatings, Loki (@tbe on github)

  • RoundSparrowMEnglish
    2·
    1 year ago

    PoWA (PostgreSQL Workload Analyzer)… how much overhead do you think this adds to a server? run in production?

    • vapelokiOPEnglish
      2·
      1 year ago

      In production, it should only be run with the remote setup. The data aggregation can get very heavy on the DB. Remote setup works fine, i have run this in large production database with nearly no impact