!Friendica Admins
Ich möchte einmal eine Beobachtung aus dem Betrieb von friendica-deutschland.de zur Diskussion stellen – ausdrücklich nicht als Schuldzuweisung an Friendica, PHP oder einzelne Komponenten.
Wir kämpfen seit längerer Zeit immer wieder mit Lastzuständen, bei denen Friendica zeitweise praktisch unbenutzbar wird. Auffällig ist dabei, dass viele php-fpm: pool web4-Prozesse gleichzeitig entstehen und parallel MariaDB sowie Friendica-Worker aktiv sind.
In der Vergangenheit haben wir mehrfach an PHP-FPM- und Friendica-Parametern gearbeitet. Das hat die Situation jeweils verbessert oder zeitlich hinausgeschoben, aber das Grundproblem nicht eindeutig erklärt.
Deshalb habe ich inzwischen einen PHP-FPM-Slowlog für die Friendica-Instanz aktiviert. Dabei zeigt sich wiederholt folgendes Muster: Lang laufende FPM-Requests hängen nicht primär in PHP-Berechnungen, sondern in externen HTTP-Aufrufen über curl_exec().
Typische Pfade sind dabei unter anderem:
HTTPSignature::fetchKey()APContact::fetch()ActivityPub\Processor::fetch()Receiver::fetchCachedActivity()Probe::webfinger()
Mehrfach treten solche Requests gleichzeitig in mehreren FPM-Prozessen auf. Das legt zumindest die Vermutung nahe, dass eingehende ActivityPub-Verarbeitung teilweise synchrone externe Abfragen nach Schlüsseln, Profilen oder Activities auslöst. Wenn entfernte Instanzen langsam oder nicht erreichbar sind, bleiben lokale FPM-Prozesse entsprechend länger belegt.
Parallel dazu zeigt Friendica bei uns zwar verzögerte Worker-Jobs, überwiegend APDelivery, die normale Worker-Warteschlange ist aber oft sehr klein. Ein klassischer dauerhaft festhängender Worker-Backlog scheint es daher nicht zu sein.
Ich möchte daraus ausdrücklich nicht ableiten, dass die Worker-Implementierung fehlerhaft ist. Ebenso wenig überzeugt mich aber die pauschale Erklärung, in solchen Fällen müsse die PHP-Umgebung „kaputt“ sein.
Für mich stellt sich vielmehr die Frage, ob wir bei Friendica stärker das Zusammenspiel aus Worker-Parallelität, PHP-FPM, MariaDB und externen Föderationspartnern betrachten sollten.
Gerade in einem föderierten Netzwerk hängt die eigene Instanz schließlich auch davon ab, wie schnell oder zuverlässig andere Systeme reagieren. Entscheidend wäre daher aus meiner Sicht nicht nur, ob Retry- und Worker-Mechanismen funktionieren, sondern auch, wie gut langsame externe Gegenstellen von der lokalen Weboberfläche entkoppelt werden.
Mich würde interessieren:
Beobachten andere Admins ähnliche Situationen, in denen viele FPM-Prozesse gleichzeitig durch externe ActivityPub-/HTTP-Abfragen gebunden sind?
Falls ja, wäre es vielleicht sinnvoll, einmal Messdaten verschiedener Instanzen miteinander zu vergleichen – statt nur einzelne Worker-, PHP- oder FPM-Parameter gegeneinander auszuspielen.
Ein zweiter Punkt beschäftigt mich ebenfalls: Häufig wird Interessierten empfohlen, Friendica auf sehr kleinen Systemen zu betreiben. Natürlich kann Friendica dort technisch laufen. Aber „läuft“ und „bleibt unter realer Föderationslast stabil“ sind für mich zwei unterschiedliche Aussagen.
Vielleicht wäre es langfristig hilfreich, realistische Erfahrungswerte für kleine, mittlere und stärker föderierte Instanzen zu sammeln – inklusive CPU, RAM, Datenbank, PHP-FPM und Worker-Konfiguration.
wuffel mag das.
teilten dies erneut
Michael 🇺🇦
Als Antwort auf Steffen 🦉🇪🇺 • • •Steffen 🦉🇪🇺
Als Antwort auf Michael 🇺🇦 • •wuffel mag das.
Friendica Admins hat dies geteilt.
Lasse Gismo (Friendica Antifa)
Als Antwort auf Michael 🇺🇦 • • •Wollte ich eben machen, da steht aber "Aktiviere dies nur auf schnellen Systemen."
Ist ein Einzelnutzern RasPi5 ein solches?
@Steffen 🦉🇪🇺
Michael 🇺🇦
Als Antwort auf Lasse Gismo (Friendica Antifa) • • •Lasse Gismo (Friendica Antifa)
Als Antwort auf Michael 🇺🇦 • • •Hab's wieder deaktiviert, die Queue ist auf 170 angewachsen.
tom s
Als Antwort auf Steffen 🦉🇪🇺 • • •Alles soweit Nachvollziehbar. Der Kern ist aber ein lokales Thema. Das lässt sich eher bei Dir lösen, als es dem Fediversum zuzuschieben. Dass die AP-Verarbeitung Keys, Profile und Aktivitäten synchron per curl holt, ist dokumentiertes Verhalten. Das gehört ins FPM-Budget. DNS- und curl-Timeouts knapp setzen. request_terminate_timeout als Notbremse. pm.max_children am realen Durchsatz ausrichten. Wer trotz mehrfacher Parameterarbeit weiterhin Pool-Exhaustion sieht, hat meist keine große Erklärungslücke.
Bevor du über Worker- oder PHP-Probleme spekulierst, helfen dabei drei Zahlen. Der Anteil der FPM-Kinder in curl_exec. Die Wartezeit je Gegenstelle aus dem slowlog und die Top-Queries aus dem MariaDB-Slow-Log. Daraus ergibt sich, wer Deine Prozesse fesselt. Eine Stunde awk auf eigenen Traces liefert dir außerdem die langsamsten Gegenstellen. Der Punkt mit den kleinen Systemen ist wirklich berechtigt. Doch Minimalvoraussetzungen waren nie eine Stabilitätsgarantie unter voller Föderationslast. Wer klein startet, nimmt das Risiko bewusst mit. Der Kern ist die Entkopplung. Extern verursachte Wartezeit gehört nicht in den Webpfad.
Steffen 🦉🇪🇺
Als Antwort auf tom s • •Danke, das hilft mir weiter. Dass die synchronen curl-Aufrufe dokumentiertes Verhalten sind, war genau der Punkt, den ich bisher nicht sicher einordnen konnte.
Eine Verständnisfrage dazu: Du schreibst einerseits, diese synchronen Abfragen gehören ins FPM-Budget, andererseits „extern verursachte Wartezeit gehört nicht in den Webpfad“. Wie ist das gemeint? Gerade diese extern verursachte Wartezeit sehe ich ja im FPM-Slowlog innerhalb von HTTPSignature::fetchKey(), APContact::fetch() und ActivityPub\Processor::fetch().
Und womit würdest du die Wartezeit je Gegenstelle konkret erfassen? Der PHP-FPM-Slowlog liefert mir aktuell nur den Stacktrace, aber weder Zielhost noch Dauer des einzelnen curl-Aufrufs.
Friendica Admins hat dies geteilt.
tom s
Als Antwort auf Steffen 🦉🇪🇺 • • •@Steffen 🦉🇪🇺
Es geht um Ist-Zustand und Soll-Zustand. 😀
pm.max_children, Timeouts und Prozesszahl so ausgelegt sein, dass eine ganze Reihe von Kindern warten darf, ohne dass der Pool für echte Arbeit erschöpft. Wer das ignoriert, belegt seine Prozesse mit Wartezeit statt mit Rechenarbeit – und genau das siehst du im Slowlog.
„Gehört nicht in den Webpfad“ sollte das Ziel sein: Die Synchronität blockiert drei Dinge auf einmal. Dein FPM-Kind ist belegt, ohne zu rechnen. Der Absender wartet auf die Antwort. Und jede langsame Gegenstelle hält nachgelagerte Requests auf. Im Idealfall löst der Fetch nicht im HTTP-Request, sondern im Worker, der asynchron läuft, dann isoliert ein langsamer Remote diese eine Queue, aber nicht deine Weboberfläche. Mit Timeouts begrenzt du nur den möglichen Schaden.
Du hast Recht, der Slowlog liefert nur den Stacktrace ohne Zielhost und Dauer.
Ich gehe mal von zeitlich begrenzten Analyse aus, keiner automatisierten Lösung:
ssfür Momentaufnahmen zeigt die Verbindungen laufender FPM-Kinder samt Ziel und Kind-PID. Gut, um während eines Lastereignisses live zu sehen, wer die Kinder gerade bindet.straceauf ein einzelnes FPM-Kind für DetailsLokaler Proxy, z. B. Squid mit Access-Log. Das Access-Log gibt dir pro Zeile Zielhost und Antwortdauer. Bei HTTPS nur den Host, aber das reicht Dir schon aus.
Dann hast du eigentlich alle Daten zusammen für eine gute Auswertung.
Steffen 🦉🇪🇺
Als Antwort auf tom s • •Friendica Admins hat dies geteilt.
Lasse Gismo (Friendica Antifa)
Als Antwort auf Steffen 🦉🇪🇺 • • •Ich verfolge den Thread mit Spannung.
Meine Performanceprobleme "löse" ich derzeit per "iptables DROP" auf GotoSocial Nodes die mich mit Anfragen fluten.
Klappt mehr schlecht als Recht.
tom s
Als Antwort auf Lasse Gismo (Friendica Antifa) • • •@Lasse Gismo (Friendica Antifa) @Steffen 🦉🇪🇺
Eine iptables-Blockade ist das pragmatischste Mittel, wenn eine Gegenstelle dauerhaft flutet.
Bei DROP wartet die Gegenseite auf eine Verbindungsbestätigung, die nie kommt. Die Requests sammeln sich so als Timeouts und Retries in deren eigener Queue. Ein REJECT sendet wenigstens ein klares Signal, ein 429/503 vom Webserver würde dem Sender sogar sagen, dass er seine Rate runterdrehen soll. Das kann man ja auch zeitlich befristet machen, nicht dauerhaft.
Bei "mehr schlecht als recht" musst Du wohl noch an anderen Schrauben drehen.
Lasse Gismo (Friendica Antifa)
Als Antwort auf tom s • • •Ich beklag' mich nicht, es wurde schon besser, hab' die Worker schon rauf und runter gedreht, "slow logs" aktiviert, allerdings hapert's an der Analyse, entkoppelter Empfänger aktiviert.
Ich nähere mich einer "lebbaren" Performance.
Als nächstes plane ich "Suricata" einzusetzen.
@Steffen 🦉🇪🇺
tom s
Als Antwort auf Lasse Gismo (Friendica Antifa) • • •Ich erinnere mich an einen ähnlichen Thread mit diesem Thema.
Auf einem Raspi5 konkurriert ein IDS direkt mit PHP und mariadb um genau die Ressourcen, die Dir jetzt schon zu fehlen scheinen. Ich vermute Deine Vorstellung, die sich aber nicht erfüllen kann... Suricata nimmt dir die Regelarbeit nicht ab. Ohne eigene, gepflegte Regeln erkennt es weder, dass Gegenstelle X Deine Inbox flutet, noch die langsame Gegenstelle. Die Standard-Signaturen decken das schlicht nicht ab. Versprich Dir also anfangs nicht zuviel davon.
Zuerst die Auswertung der Slowlogs, dann entscheiden. Mein Tip bei Deinem System wäre es eher als passiver IDS statt inline-IPS zu nutzen,
Lasse Gismo (Friendica Antifa)
Als Antwort auf tom s • • •Kennst Du Dich mit Slowlog Analyse aus?
@Steffen 🦉🇪🇺
tom s
Als Antwort auf Lasse Gismo (Friendica Antifa) • • •@Lasse Gismo (Friendica Antifa)
Ich kann Dir das in so nem Chat nicht wirklich gut darbieten-
Fang zunächst ganz praktisch an: Nimm ein Tool wie
wrkund schau mal, was es Deiner Friendica-Instanz auf dem Raspi so ausmacht.Mit wenigen Verbindungen starten und dann langsam steigern.
Das Ganze in 5er-Schritten wiederholen, 10, 15, 20 Verbindungen und so weiter. Irgendwann merkst du dann,, hier wird es eng. Die Antwortzeiten werden schlechter, Timeouts, Du hast den ersten Flaschenhals gefunden.
Wichtig ist dabei, parallel ein zweites Terminal mit
htopoffen zu haben. Dort siehst du dann direkt, was auf dem System passiert. Plötzlich haufenweise PHP-Prozesse? Mariadb mit hohen CPU-Werten? Oder, ob Dein Speicher knapp wird.Das Ganze ist erstmal nur ein Schnelltest, aber er gibt Dir schon eine gute Richtung. Und vor allem hast Du jertzt konkrete Zahlen und Logs, mit denen du weiterarbeiten kannst.
Lasse Gismo (Friendica Antifa)
Als Antwort auf tom s • • •Danke vielmals.
Ich werde berichten.
Steffen 🦉🇪🇺
Als Antwort auf Steffen 🦉🇪🇺 • •Ergänzend zur bisherigen Slowlog-Auswertung konnte ich inzwischen einen Lastzustand mit
ssundstracedirekt beobachten.Dabei waren gleichzeitig zahlreiche
php-fpm8.2-Prozesse mit denselben externen HTTPS-Gegenstellen verbunden.Einen dieser Prozesse habe ich parallel mit
strace -tt -Tverfolgt. Die betreffende PID wartete rund 14 Sekunden lang nahezu ausschließlich in wiederholtenpoll()-Aufrufen auf Daten des externen HTTPS-Sockets. Überssließ sich exakt dieses File-Descriptor derselben PID der externen Verbindung zuordnen.MariaDB und Redis antworteten im selben Trace dagegen im Mikro- bzw. Submillisekundenbereich. Auch ein anschließend beobachteter DNS-Lookup und der Aufbau einer anderen HTTPS-Verbindung liefen schnell.
Damit lässt sich das bisher im PHP-FPM-Slowlog erkennbare Verhalten nun auch auf Betriebssystemebene nachvollziehen: Mehrere FPM-Kinder können gleichzeitig durch synchrone externe HTTP-Aufrufe gebunden sein, ohne dabei nennenswert CPU zu benötigen. Bei genügend parallelen Vorgängen wächst dadurch der FPM-Pool.
Die aktuelle Testkonfiguration ist deshalb:
pm.max_children = 120curl_timeout = 45 srequest_terminate_timeout = 90 sMonit: restart bei >96 Kindern für 2 Zyklen(Children If greater than 96 for 2 cycles then restart)Jetzt beobachte ich insbesondere, ob sich FPM-Spitzen damit abfangen lassen und wie sich normale und verzögerte Worker-Warteschlange dabei verhalten.
Friendica Admins hat dies geteilt.
tom s
Als Antwort auf Steffen 🦉🇪🇺 • • •@Steffen 🦉🇪🇺
Danke, dass du die Werte nun mit echten Zahlen belegst.
Zu Deiner Testkonfiguration: Mit
curl_timeout 45bindet eine tote Gegenstelle einen Prozess bis zu 45 Sekunden. Je länger der Timeout, desto mehr parallele Kinder sind gleichzeitig nötig. Wenn Du den Timeout z. B. auf 10-15s senkst, begrenzt es denselben Schaden mit deutlich wenigermax_childrenund weniger RAM-Puffer. Finde 120 Kinder schon recht viel. Vermutlich ca. 5GB RAM.Einen Monit-Restart hätte ich an dieser Stelle so gar nicht erwartet. Hmm. Ein Pool-Neustart mitten im Lastereignis bricht laufende Requests ab und verschleppt Retries. Als mögliche Notbremse vielleicht okay, aber notiere/vergleiche den Zeitpunkt eines jeden Restarts, sonst verfälscht dieser Deine Auswertung. In der Testphase würde ich erst einmal nur melden, ohne neu zu starten.
Steffen 🦉🇪🇺
Als Antwort auf tom s • •Der Monit-Restart ist tatsächlich nur als vorläufige Notbremse gedacht, nicht als eigentliche Lösung.
Hintergrund war, dass bei den bisherigen Ereignissen der FPM-Pool so stark anwuchs, dass Friendica für die Benutzer merklich ins Stocken kam. Mit dem Restart wollte ich in erster Linie verhindern, dass die Instanz über längere Zeit praktisch unbenutzbar wird.
Mir ist bewusst, dass ein Restart während eines Lastzustands laufende Requests abbricht und dadurch auch Retries beeinflussen kann. Für eine saubere Testphase ist Dein Hinweis deshalb sinnvoll: Ich kann Monit zunächst nur noch melden lassen und die Zeitpunkte der Lastspitzen bzw. eventueller Pool-Erschöpfung dokumentieren, ohne direkt neu zu starten.
Den curl_timeout von 45 Sekunden sehe ich ebenfalls erst einmal als konservativen Zwischenschritt. Wenn sich anhand der weiteren Messungen zeigt, dass 10–15 Sekunden für die Federation ausreichend sind, wäre das natürlich wesentlich eleganter als immer mehr FPM-Kinder vorzuhalten.
Friendica Admins hat dies geteilt.
tom s
Als Antwort auf Steffen 🦉🇪🇺 • • •„Konservativer Zwischenschritt“ ist gut formuliert. Bei Gegenstellen, die komplett dead laufen, also keine ACK, unerreichbar, ist curl_timeout 45 lang. Jede tote Gegenstelle bindet damit bis zu 45 Sekunden, und bei 120 belegten Kindern hältst du im Worst Case 120 × 45 s Wartezeit im Puffer, auch wenn sie sich überlappen. Greift dann noch der Monit-Restart in diesen Zustand ein ... Ausprobieren.
Steffen 🦉🇪🇺
Als Antwort auf tom s • •Danke für den Hinweis. Ich habe die Werte jetzt weiter reduziert auf:
curl_timeout = 20srequest_terminate_timeout = 60spm.max_children = 120lasse ich zunächst unverändert, damit wir möglichst nur den Einfluss der kürzeren Wartezeiten beobachten.Jetzt warte ich auf den nächsten echten Lastfall und vergleiche dann wieder FPM-Kinderzahl, Slowlog sowie ss/strace.
Deinen Hinweis zum Monit-Restart habe ich ebenfalls im Hinterkopf; der ist weiterhin nur als Notbremse gedacht und soll die Auswertung möglichst nicht verfälschen.
Friendica Admins hat dies geteilt.
Steffen 🦉🇪🇺
Als Antwort auf Steffen 🦉🇪🇺 • •Nach mehreren Tagen Messung möchte ich unsere Untersuchung zum ungewöhnlich
anwachsenden PHP-FPM-Pool abschließen.
Der wichtigste Befund ist inzwischen recht eindeutig:
Von 196.466 ausgewerteten Slowlog-Ereignissen enthielten 195.069 einen
curl_exec()-Aufruf, also rund 99,3 Prozent.Zusätzlich konnten wir einen betroffenen PHP-FPM-Prozess während eines realen
Ereignisses mit
ssundstracebeobachten. Dabei wartete der Prozess über viele Sekunden wiederholt inpoll()auf Daten eines externen HTTPS-Sockets. Überssließsich derselbe File-Descriptor derselben PID eindeutig einer externen Verbindung zuordnen. Gleichzeitig bestanden mehrere weitere PHP-FPM-Verbindungen zu denselben wenigen Gegenstellen.MariaDB und Redis antworteten im selben Zeitraum dagegen sehr schnell. Der Engpass
lag also nicht primär im lokalen System, sondern im Warten auf externe HTTP-
Kommunikation.
Nach der schrittweisen Anpassung der Wartezeiten und der FPM-Reserve hat sich das
Verhalten deutlich beruhigt. Auch der Load Average ist wieder auf ein normales Niveau
zurückgegangen. Die Zahl der Slowlog-Ereignisse fiel ab dem 4. September massiv ab.
Der Slowlog ist deshalb inzwischen wieder deaktiviert.
Mein persönliches Fazit aus der Untersuchung geht inzwischen über die konkrete
Friendica-Instanz hinaus:
Eine föderierte Instanz muss nicht nur selbst stabil laufen. Sie muss auch so mit
langsamen, fehlerhaften oder zeitweise unerreichbaren Gegenstellen umgehen können,
dass deren Zustand die eigene Funktionsfähigkeit möglichst wenig beeinflusst.
Ich habe die Ergebnisse deshalb noch einmal ausführlicher in einem Fachartikel
zusammengefasst:
Föderation braucht Fehlertoleranz an den Instanzgrenzen
Hier der vollständige Artikel
Dabei verzichte ich bewusst auf konkrete Grenzwerte oder eine allgemeine „Best-Practice-
Konfiguration“. Die Werte hängen zu stark von Instanzgröße, Nutzung, Federation-
Volumen und Systemumgebung ab. Entscheidend ist aus meiner Sicht nicht das Kopieren
einzelner Parameter, sondern das Verständnis der Zusammenhänge und die Messung auf
der eigenen Instanz.
#Friendica #Fediverse #Sysadmin #ActivityPub #Federation
Friendica Admins hat dies geteilt.
tom s
Als Antwort auf Steffen 🦉🇪🇺 • • •Wie langsame oder fehlerhafte Gegenstellen die eigene Instanz belasten können ist genau die richtige Frage. Und diese Messung gibt auch eine Antwort. Slowlog, ss und strace sind sauber eingesetzt. Die 14 Sekunden in poll() machen es sichtbar: Ein FPM-Pool wächst, weil Requests auf langsame Gegenstellen warten. Statt nach der Ursache in der eigenen Kette zu fragen, wird ein Gegenargument konstruiert. Der Halbsatz "mehr als die Summe gut administrierter Server“ trägt das nicht. Die Belastung entsteht eben nicht durch die Föderation, sondern durch die eigene Konfiguration. Friendica bringt dafür solide Einstellmöglichkeiten schon mit, so dass eine Instanz mit Standardwerten kein Netzwerkproblem hat. Sie hat ein Administrationsproblem. Timeouts, Backoff und begrenzte Verbindungen lösen das, nicht die Forderung an andere Systeme. Die Schwäche fremder Instanzen muss keine eigenen Ressourcen binden. Dass die Zahlen nach dem Finetuning drastisch fielen, beweist doch das Gegenteil. Genau die Summe gut administrierter Server macht das Netz robust.
Steffen 🦉🇪🇺
Als Antwort auf tom s • •Ich glaube, wir liegen technisch näher beieinander, als es zunächst wirkt.
Dass die konkrete Belastung auf meiner Instanz durch lokale Parameter begrenzt werden konnte, bestreite ich nicht – im Gegenteil, genau das zeigen die Messungen.
Mein Punkt ist aber ein anderer: In einem föderierten System muss ich grundsätzlich damit rechnen, dass Gegenstellen langsam, fehlerhaft oder schlecht konfiguriert sind. Deshalb gehört es für mich zur Robustheit einer föderierten Instanz, diese Unterschiede sauber abzufangen.
Das ist keine Forderung an die fremde Instanz und auch keine Verlagerung der Verantwortung. Die Verantwortung bleibt lokal. Aber die Ursache des Lastpfades entsteht eben erst durch die Kommunikation mit einer langsamen Gegenstelle.
Deshalb sehe ich beides gleichzeitig als richtig an:
Die konkrete Abfederung ist Aufgabe der eigenen Instanz.
Die Notwendigkeit dieser Abfederung entsteht aus der Natur eines heterogenen föderierten Netzes.
Genau diesen Zusammenhang wollte ich mit dem Artikel herausarbeiten.
Friendica Admins hat dies geteilt.
tom s
Als Antwort auf Steffen 🦉🇪🇺 • • •@Steffen 🦉🇪🇺
Das ist doch ein Artikel auf einem Admin-Blog. Dass es da langsame Gegenstellen im Netz gibt, kann man gerne in einem Nebensatz erwähnen, aber ausschlaggebend ist es nicht wirklich.
Ein praktischer Zusatz: In Friendica läuft ein Großteil des Föderationsverkehrs über curl – Verzögerungen entstehen erst dort, wo HTTP-Aufrufe gemacht werden. Und genau davor kann man regulieren: Wer ankommenden Traffic früh am Edge begrenzt (Timeouts im Webserver, Max-Clients, Slow-Start-Erkennung), lässt das Problem gar nicht erst bis zu PHP-FPM durchdringen. Was nie bei PHP ankommt, hält auch kein FPM-Kind besetzt. Ich lese da als erste Reaktion meist ein
DROP mit ufw oder iptables.
"Das Problem war zunächst schwer einzugrenzen. Der Server selbst bot keine offensichtliche Erklärung.“ Ein echter Klassiker. Der Server kennt die Ursache natürlich selbst nicht, er sagt nur brav "poll() wartet“. Erklärungen liefert erst das Slowlog. ;)
Dein Artikel ist schon wertvoll: Die Kette vom eingehenden Request bis zum wartenden curl-Aufruf im FPM-Kind sichtbar zu machen, ist genau die richtige Diagnose-Ebene. Ich wünsche mir nur, dass diese Message ankommt.
Das Netz ist nicht das Problem, die häufig verwendeten Werkzeuge der Admins sind es.
Steffen 🦉🇪🇺
Als Antwort auf Steffen 🦉🇪🇺 • •Ich glaube, wir drehen uns inzwischen weniger um die technische Diagnose als um die Perspektive darauf.
Bei der lokalen Verantwortung sind wir uns im Grunde einig: Eine Instanz muss so konfiguriert und betrieben werden, dass langsame oder fehlerhafte Gegenstellen die eigenen Ressourcen nicht unnötig binden.
Mein Punkt geht nur einen Schritt weiter. Eine Friendica-Instanz ist kein isolierter Webserver, sondern Teilnehmer eines heterogenen föderierten Netzes. In diesem Netz gibt es zwangsläufig schnelle, langsame, gut und schlecht administrierte Instanzen. Genau diese Unterschiedlichkeit gehört für mich zur Betriebsrealität.
Deshalb sehe ich die Situation nicht ausschließlich als „lokales Administrationsproblem“. Das lokale Problem entsteht innerhalb einer föderierten Umgebung, deren Teilnehmer unvermeidbar unterschiedlich reagieren. Die Aufgabe des Admins besteht darin, die eigene Instanz gegen genau diese Realität robust zu machen.
Deine Hinweise zu Timeouts, Begrenzungen und früher Filterung am Edge - also zum Beispiel Firewall-Regeln - sind als Schutzmechanismen sinnvoll. Sie ändern für mich aber nichts an der grundsätzlichen Erkenntnis: Die Ursache des konkreten Lastpfades lag in der Kommunikation mit externen Gegenstellen, und die lokale Konfiguration entscheidet darüber, wie stark sich diese Rahmenbedingung auswirkt.
Genau diesen Zusammenhang wollte ich mit dem Artikel darstellen. Nicht als Forderung an andere Instanzen, sondern als Hinweis darauf, dass Föderation auch bedeutet, die eigene Instanz auf ein ungleichmäßiges und teilweise fehlerhaftes Netz vorzubereiten.
Ich denke, damit ist unsere unterschiedliche Sichtweise ausreichend klar geworden. Bei der Diagnose selbst liegen wir ohnehin sehr nah beieinander.
Friendica Admins hat dies geteilt.