01a0808a-09c5-7049-8b9c-534064378ec2
post
-
01a0808a-09c5-7049-8b9c-534064378ec2
0
Stefan Wintermeyer
https://vutuv.de/wintermeyer/posts/01a0808a-09c5-7049-8b9c-534064378ec2
2026-09-08
AFAIK ist Mastodon im Kern eine Ruby on Rails Applikation. Das ORM wäre dann ActiveRecord. Eigentlich ist ActiveRecord nicht schlecht und generiert auch brauchbares SQL. Aber es kann natürlich nicht suboptimale Programmierung ausbügeln. Das hier ist kein Framework oder ORM Problem. Da hat jemand beim Programmieren nicht bis ans Ende gedacht.
Schaue Dir mal die https://abuuba.com Benchmark Vergleichswerte an. Bei Mastodon gibt es noch viel Optimierungspotential.
wintermeyer
-
01a080bd-85ce-7c62-b98f-523ae120ae7a
1
René Oelke
https://vutuv.de/reneoelke/posts/01a080bd-85ce-7c62-b98f-523ae120ae7a
2026-09-08
01a0808a-09c5-7049-8b9c-534064378ec2
@wintermeyer Eines der Optimierungspotentiale scheint wohl auch Storage und Caching zu sein. Ist das in abuuba anders oder sogar besser gelöst?
reneoelke
Stefan Wintermeyer
-
01a080c2-6b1c-7e87-b58b-41b4d6dcfeb9
2
Stefan Wintermeyer
https://vutuv.de/wintermeyer/posts/01a080c2-6b1c-7e87-b58b-41b4d6dcfeb9
2026-09-08
01a080bd-85ce-7c62-b98f-523ae120ae7a
Ich bin ja ein großer Fan vom Caching. Aber Caching funktioniert nur richtig gut, wenn die Grundlagen dahinter sauber geplant und programmiert wurden.
Mastodon hat diesbezüglich Raum für Verbesserungen.
abuuba hat es aber auch einfacher. Es ist immer einfacher Fehler anderer zu sehen und diese dann nicht zu wiederholen, als selbst auch von Null anzufangen.
wintermeyer
René Oelke
-
01a080ef-7746-7789-9bdc-c4d97a2dbc5d
1
Stefan Wintermeyer
https://vutuv.de/wintermeyer/posts/01a080ef-7746-7789-9bdc-c4d97a2dbc5d
2026-09-08
01a0808a-09c5-7049-8b9c-534064378ec2
Ja, das kenne ich aus meinem beruflichen Alltag auch nur zu gut. Es mangelt oft an den Grundlagen. Wenn dann noch eine "Schicht" Caching drüber gelegt wird, dann wundert sich jeder, warum bei jeder zweiten Abfrage falsche Ergebnisse rauskommen.
wintermeyer
Stefan Wintermeyer
AFAIK ist Mastodon im Kern eine Ruby on Rails Applikation. Das ORM wäre dann ActiveRecord. Eigentlich ist ActiveRecord nicht schlecht und generiert auch brauchbares SQL. Aber es kann natürlich nicht s
Stefan Wintermeyer · 2026-09-08
Stefan Wintermeyer
wintermeyer
https://vutuv.de/wintermeyer
-
René Oelke
https://vutuv.de/reneoelke/posts/01a080bd-85ce-7c62-b98f-523ae120ae7a
2026-09-08
@wintermeyer Eines der Optimierungspotentiale scheint wohl auch Storage und Caching zu sein. Ist das in abuuba anders oder sogar besser gelöst?
reneoelke
-
Stefan Wintermeyer
https://vutuv.de/wintermeyer/posts/01a080ef-7746-7789-9bdc-c4d97a2dbc5d
2026-09-08
Ja, das kenne ich aus meinem beruflichen Alltag auch nur zu gut. Es mangelt oft an den Grundlagen. Wenn dann noch eine "Schicht" Caching drüber gelegt wird, dann wundert sich jeder, warum bei jeder zweiten Abfrage falsche Ergebnisse rauskommen.
wintermeyer
https://vutuv.de/wintermeyer/posts/01a0808a-09c5-7049-8b9c-534064378ec2
https://vutuv.de/wintermeyer/posts/01a0808a-09c5-7049-8b9c-534064378ec2.json
https://vutuv.de/wintermeyer/posts/01a0808a-09c5-7049-8b9c-534064378ec2.txt
https://vutuv.de/wintermeyer/posts/01a0808a-09c5-7049-8b9c-534064378ec2.md
https://vutuv.de/wintermeyer/posts/01a0808a-09c5-7049-8b9c-534064378ec2.xml
- performance
- sql
- Mastodon
- ActiveRecord
- Geschwindigkeit
Werfe einen Blick in das PostgrSQL-Log. In dem werden auch long-running-Queries protokolliert. Und was sehe ich da? #Mastodon macht:
SELECT "tags".* FROM "tags" WHERE "tags"."id" IN ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, […] $5272, $5273, $5274) AND "tags"."id" > $5275 ORDER BY "tags"."id" ASC LIMIT $5276
Heiliger Bimbam, 5276 Bind-Parameter. Wer baut sowas … – sieht nach irgendeinem gammeligem ORM aus.
Ja, natürlich sind Bind-Parameter richtig und korrekt. Aber doch nicht über 5000!
Die kommen doch garantiert auch aus der DB. SQL kann sowas wie:
SELECT * FROM tags WHERE id IN (SELET tag_id FROM <wasauchimmer> WHERE <bedingung>) AND id > $1 ORDER BY id ASC LIMIT $2;
Allerdings riecht "id > $x" irgendwie auch nach einem schlechten Datenbank-Modell.
@alvar@freude.social
https://freude.social/users/alvar/statuses/117231286402674628
fediverse
1
2026-09-08T14:18:51Z
3
2026-09-08
0
3
-
@alvar@freude.social
@wintermeyer@vutuv.de ja, mastodon ist Ruby on Rails. Welches ORM verwendet wird weiß ich nicht.
In Sachen SQL ist „siboptimale Programmierung“ leider Standard. Sehe ich sehr sehr häufig. Habe früher als Freiberufler u.a. PostgreSQL Performance-Tuning gemacht. Oft wurden noch nicht mal die Grundlagen beherrscht.
Alvar Freude
https://freude.social/@alvar/117235343788928300
2026-09-08T12:09:42Z
freude.social
AFAIK ist Mastodon im Kern eine Ruby on Rails Applikation. Das ORM wäre dann ActiveRecord. Eigentlich ist ActiveRecord nicht schlecht und generiert auch brauchbares SQL. Aber es kann natürlich nicht suboptimale Programmierung ausbügeln. Das hier ist kein Framework oder ORM Problem. Da hat jemand beim Programmieren nicht bis ans Ende gedacht.
Schaue Dir mal die https://abuuba.com Benchmark Vergleichswerte an. Bei Mastodon gibt es noch viel Optimierungspotential.
0
0
1
-
René Oelke
reneoelke
https://vutuv.de/reneoelke
0
0
false