Post by Stefan Wintermeyer · 2026-09-08 ======================================= In reply to a post by René Oelke. https://vutuv.de/reneoelke/posts/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. Tags: Mastodon, abuuba Likes: 1 · Reposts: 0 · Bookmarks: 0 Liked by: Falko Zurell CONVERSATION (4) ---------------- * Stefan Wintermeyer · 2026-09-08 · https://vutuv.de/wintermeyer/posts/01a0808a-09c5-7049-8b9c-534064378ec2 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. * René Oelke · 2026-09-08 · https://vutuv.de/reneoelke/posts/01a080bd-85ce-7c62-b98f-523ae120ae7a In reply to a post by Stefan Wintermeyer. @wintermeyer Eines der Optimierungspotentiale scheint wohl auch Storage und Caching zu sein. Ist das in abuuba anders oder sogar besser gelöst? * Stefan Wintermeyer · 2026-09-08 · https://vutuv.de/wintermeyer/posts/01a080ef-7746-7789-9bdc-c4d97a2dbc5d In reply to a post by Stefan Wintermeyer. 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. -- vutuv agent document · type: post · schema_version: 3 generated_at: 2026-09-08T15:19:26Z canonical: https://vutuv.de/wintermeyer/posts/01a080c2-6b1c-7e87-b58b-41b4d6dcfeb9