Axel (XL)
Open Source Enthusiast. IT Professional.
Ich bin vor allem ein Fan von rationalen Entscheidungen auf Basis gründlicher Recherche. Bei differierenden Ansichten interessieren mich daher besonders die Erfahrungen/Datengrundlagen der Gegenseite. Denn die müssen ja anders sein als meine, sonst wären wir ja zu derselben Ansicht gelangt.
An deine öffentlichen Posts, Kommentare, Bilder, etc. im Fediverse kommt jeder anonym (über die API) jetzt schon ran. Das Problem ist eher die Privacy Policy der Threads App und die ist geradezu haarsträubend. Aber die App nutzt du ja gerade nicht, wenn du mit Threads von Mastodon aus kommunizierst.
Threads App im Apple App Store
Das Problem mit Dreckschleudern hat das Fediverse natürlich selbst auch. Der dicke Deföderations-Hammer wird u. a. auch deswegen 'rausgeholt, weil für ein feinkörnigeres Moderieren Werkzeuge und Leute fehlen. Dummerweise skaliert dieser Hammer aber mit der Größe der Instanz, auf den man ihn draufhaut, und Hammer sind notorisch schlecht im genau Hingucken. 😀
- Bislang ist ActivityPub noch gar nicht in Threads implementiert, d. h. man kommt aus dem Fediverse momentan sowieso noch nicht 'ran.
- In Europa ist Threads aufgrund von strikteren Datenschutz-Bestimmungen momentan gar nicht verfügbar.
- Die FOSS-Alternative zu Threads bzw. Twitter ist eher Mastodon als Lemmy bzw. Kbin.
Richtig, das Blocken von threads.net auf Mastodon Servern verhindert (in der Zukunft), dass Nutzer von dort mit Nutzern auf Threads kommunizieren und führt eventuell dazu, dass sich dann jemand doch bzw. auch noch bei Threads anmeldet.
Soweit ich weiß, geht das nicht und wird vermutlich in naher Zukunft auch nicht implementiert. Ich habe die folgenden drei Issues dazu auf GitHub gefunden:
- https://github.com/LemmyNet/lemmy/issues/3057
- https://github.com/LemmyNet/lemmy/issues/1985
- https://github.com/LemmyNet/lemmy/issues/506
Bei Mastodon gibt es dafür ein paar Möglichkeiten:
Naja, die Implementierunsgsprache ist zwar auch wichtig, aber das Design von Protokollen, Datenstrukturen, Code/Concurrency und Infrastruktur ist gar nicht so sehr abhängig davon. Das ist mir schon oft in der OOP-Welt aufgefallen. Nur weil etwas in einer objektorientierten Sprache implementiert ist, hat es nicht automatisch ein gutes bzw. gut skalierbares Design. Ähnliches gilt auch für Rust oder Golang, obwohl beide natürlich spezielle Stärken haben wie memory safety und concurrency.
📓 Das ist die Info, die ich gefunden habe:
Vermutlich macht es Sinn, sich direkt mit @ruud@lemmy.world in Verbindung zu setzen. Mein Eindruck ist, dass er ziemlich kooperativ ist.
The solutions
What I had noticed previously, is that the lemmy container could reach around 1500% CPU usage, above that the site got slow. Which is weird, because the server has 64 threads, so 6400% should be the max. So we tried what @sunaurus@lemm.ee had suggested before: we created extra lemmy containers to spread the load. (And extra lemmy-ui containers). And used nginx to load balance between them.
Et voilà. That seems to work.
Also, as suggested by him, we start the lemmy containers with the scheduler disabled, and have 1 extra lemmy running with the scheduler enabled, unused for other stuff.
There will be room for improvement, and probably new bugs, but we’re very happy lemmy.world is now at 0.18.1-rc. This fixes a lot of bugs.
🖥 Letzte mir bekannte Info zur Hardware:
Update The server was migrated. It took around 4 minutes downtime. For those who asked, it now uses a dedicated server with a AMD EPYC 7502P 32 Cores “Rome” CPU and 128GB RAM. Should be enough for now.
You could try the fix that was proposed here:
https://github.com/LemmyNet/lemmy-ansible/issues/106#issuecomment-1606222766
This basically changes the way that nginx (nginx_internal.conf) switches between Backend and Frontend depending on the content type specified in the request.