Fragen und Feedback zum Betreiberwechsel/Migration des Forums

[Kolinatan]

Meinst Du "Grün" entsprach der Identität von Menschen mit der Genkombination XXY? Oder meinst Du Menschen mit psychischer Indifferenz?

"Grün" war die Option für Menschen die auf Formularen "Geschlecht: [x] Divers(es?)" ankreuzen und irgendwo in der großen Menge LGBTQ+whatever stecken. Mehr verstehe ich davon nicht und es ist mir persönlich (Mann) auch egal, ich sehe nur Menschen.

Nein, war es nicht. Die Option "Grün" war ein Joke. Dessen Hintergründe vor über 10 Jahren bereits nicht mehr ganz klar waren. Lange bevor die Politik auf das Thema aufgesprungen ist. Es gibt zwei Interpretationen worauf der Eintrag zurück geht: entweder weil Moderatoren grün sind oder wegen diesem Smiley .

Die Option hatte mit LGBTQ+ nie etwas zu tun. So sehr war das Forum seiner Zeit auch nicht voraus.

[Mit müden Augen]

Ja ok, vielleicht war das damals ein Witz, aber ich weiß von mindestens einer Person die die Option als Synonym für Diverses ausgewählt hat. Wie auch immer, ich bin nicht betroffen und somit kann es mir egal sein...

[Mit müden Augen]

Ganz was anderes: Es sind wieder deutlich mehr Bots als vor der Migration unterwegs, nicht nur Bing und Google. Der Server/das Forum scheint keine robots.txt zu haben. Ist das Absicht oder fehlt da was?

[Kolinatan]

Ganz was anderes: Es sind wieder deutlich mehr Bots als vor der Migration unterwegs, nicht nur Bing und Google. Der Server/das Forum scheint keine robots.txt zu haben. Ist das Absicht oder fehlt da was?

Ich habe die alte robots.txt nicht übernommen. Für die Serverlast sind die Bots kein Thema. Wenn es zu Problemen wegen der Leistung kommen sollte, kann ich immer noch Einschränkungen vorsehen.

[Milchbub]

Wann ist er von uns gegangen? Am 28. Oktober 2021?

ja! siehe hier

Danke!

[Kolinatan]

Welche Bedeutung die Performanz der Datenbank hat, könnt Ihr sehen, wenn Ihr Euch die letzte Zeile "Time: 0.xxxs" einer Seite anschaut. Die Zeiten schwanken bei mir zwischen 0,1s bis 0,5s. Wenn Ihr Euch den Quelltext anschaut, dann steht dort z.B. für "Time: 0.280s" sogar die Aufteilung: "SQL time: 0.268s / PHP time: 0.012s".

Ich möchte gern wissen, ob Ihr aktuell noch Momente habt bei denen die Zeiten für den Seitenabruf stark schwanken. Insbesondere ob es noch Peaks bei der SQL time gibt. Seit dem Umzug hatte ich beim Posten von Beiträgen bisher keine Verzögerung mehr erlebt. Während vorher bei jedem 5.-10. Post das Absenden mitunter mehrere Sekunden gedauert hat.

[The Poet]

Wann ist er von uns gegangen? Am 28. Oktober 2021?

ja! siehe hier

Knapp 2 Jahre ist das schon her? Meine Güte, wie die Zeit verfliegt...

Welche Bedeutung die Performanz der Datenbank hat, könnt Ihr sehen, wenn Ihr Euch die letzte Zeile "Time: 0.xxxs" einer Seite anschaut. Die Zeiten schwanken bei mir zwischen 0,1s bis 0,5s. Wenn Ihr Euch den Quelltext anschaut, dann steht dort z.B. für "Time: 0.280s" sogar die Aufteilung: "SQL time: 0.268s / PHP time: 0.012s".

Ich möchte gern wissen, ob Ihr aktuell noch Momente habt bei denen die Zeiten für den Seitenabruf stark schwanken. Insbesondere ob es noch Peaks bei der SQL time gibt. Seit dem Umzug hatte ich beim Posten von Beiträgen bisher keine Verzögerung mehr erlebt. Während vorher bei jedem 5.-10. Post das Absenden mitunter mehrere Sekunden gedauert hat.

Ich hab auch das Gefühl, dass das aufgehört hat ... aber bislang ist es nur ein Gefühl. (Aber ergäbe ja Sinn... "früher" [ich nehme an, damals noch bei einem gekauften Hostingangebot] hatten wir das Problem meines Wissens praktisch nicht, seitdem dann auf den "Home"-Server vom vorigen Admin gewechselt wurde [auch wenn ich das ja erst jetzt in retrospect erfahren habe und somit diesen Schluss ziehen kann], ist es hin und wieder aufgetreten, und jetzt sind wir halt wieder bei nem Hoster, der das professionell/"in großem Stil" macht, und offenbar kein "Schluckauf" hat .
Wäre interessant zu wissen, warum genau das Problem bei dem Home-Server aufgetreten ist bzw. was genau es verursacht hat, aber das wird wohl in die Liste der unresolved mysteries eingehen... außer wir können Mulder & Scully von den X-Files für den Fall begeistern .)

[Don Rosa]

Es war kein "Home"-Server unterm Schreibtisch, sondern bei Hetzner.

[The Poet]

Es war kein "Home"-Server unterm Schreibtisch, sondern bei Hetzner.

Ok. Dann nehme ich mein Statement zurück. Dann ergibt der Schluckfauf Null Sinn.

[halbkaputt]

ist es hin und wieder aufgetreten, und jetzt sind wir halt wieder bei nem Hoster, der das professionell/"in großem Stil" macht, und offenbar kein "Schluckauf" hat .

das hat jetzt weniger was mit professionell zu tun als mit den Skaleneffekten. bei einem shared hosting Paket bist du eine Webseite von tausenden auf einem extrem dicken Server. und wenn die "Nachbarn" auf dem Server gerade keinen Traffic haben, hast du den dicken Server für dich allein
wenn zwei Mitglieder gerade gleichzeitig auf "antworten" klicken, hat der SQL server auf einem kleinen Einzelsystem(der bei einem gemieteten Rootserver mit dem Webserver und anderen Dingen auf der gleichen Hardware läuft) wesentlich weniger Möglichkeiten das schnell wegzuschaffen

[The Poet]

ist es hin und wieder aufgetreten, und jetzt sind wir halt wieder bei nem Hoster, der das professionell/"in großem Stil" macht, und offenbar kein "Schluckauf" hat .

das hat jetzt weniger was mit professionell zu tun als mit den Skaleneffekten. bei einem shared hosting Paket bist du eine Webseite von tausenden auf einem extrem dicken Server. und wenn die "Nachbarn" auf dem Server gerade keinen Traffic haben, hast du den dicken Server für dich allein
wenn zwei Mitglieder gerade gleichzeitig auf "antworten" klicken, hat der SQL server auf einem kleinen Einzelsystem(der bei einem gemieteten Rootserver mit dem Webserver und anderen Dingen auf der gleichen Hardware läuft) wesentlich weniger Möglichkeiten das schnell wegzuschaffen

D.h. deine bzw. die von dir implizit vorgeschlagene Theorie wäre: Beim alten System (vorm Wechsel zum aktuellen Angebot, betreut von Kolinatan) war die Dimensionierung der Hardware schlichtweg nicht groß genug für die Foren-Nutzungs-Peaks?

Warum hat es dann auch nachts häufiger mal so lange gedauert? Um die Zeit sollten doch Traffic und Server-Belastung ziemlich niedrig sein?

[halbkaputt]

D.h. deine bzw. die von dir implizit vorgeschlagene Theorie wäre: Beim alten System (vorm Wechsel zum aktuellen Angebot, betreut von Kolinatan) war die Dimensionierung der Hardware schlichtweg nicht groß genug für die Foren-Nutzungs-Peaks?

das ist nicht nur eine Frage von Größe. in richtiger Server Hardware(die für das Rootservergeschäft zu teuer ist) kommen noch ein paar andere Dinge dazu wie z. B. SAS vs SATA vs. NVME oder ECC vs non-ECC RAM. um mal ein Beispiel aufzumachen: Bit im Speicher in dem das gerade empfangene TCP Segment ist kippt. mit ECC wird das praktisch ohne Verzögerung korrigiert! bei NON-ECC muss erst die Checksummenkalkulation durchlaufen und fehlschlagen, damit der TCP/IP Stack das Paket nochmal anfordern kann bis der retry der Gegenseite im Speicher ist, ist schon 2x eine round trip time vergangen

Warum hat es dann auch nachts häufiger mal so lange gedauert? Um die Zeit sollten doch Traffic und Server-Belastung ziemlich niedrig sein?

im nachhineinschwer zu sagen, aber solche Verzögerung sprechen doch am ehesten für IOWAIT. d. h. der Kernel blockiert Prozesse, die gleichzeitig auf das gleiche device zugreifen wollen. hier wäre z. B. mechanische Festplatte(die wenig IOPs hat) vs. SSD eine Möglichkeit. es ist ja davon auszugehen, dass noch ein Haufen "Maintenace-Zeug" läuft, dass auch auf die Festplatte zugreift(Backup, unattended-upgrades, usw.)

[The Poet]

D.h. deine bzw. die von dir implizit vorgeschlagene Theorie wäre: Beim alten System (vorm Wechsel zum aktuellen Angebot, betreut von Kolinatan) war die Dimensionierung der Hardware schlichtweg nicht groß genug für die Foren-Nutzungs-Peaks?

das ist nicht nur eine Frage von Größe. in richtiger Server Hardware(die für das Rootservergeschäft zu teuer ist) kommen noch ein paar andere Dinge dazu wie z. B. SAS vs SATA vs. NVME oder ECC vs non-ECC RAM. um mal ein Beispiel aufzumachen: Bit im Speicher in dem das gerade empfangene TCP Segment ist kippt. mit ECC wird das praktisch ohne Verzögerung korrigiert! bei NON-ECC muss erst die Checksummenkalkulation durchlaufen und fehlschlagen, damit der TCP/IP Stack das Paket nochmal anfordern kann bis der retry der Gegenseite im Speicher ist, ist schon 2x eine round trip time vergangen

Ok, wie oft kommt sowas vor, statistisch gesprochen? Ein one-in-one-thousand oder eher ein ≤one-in-one-billion-Ereignis? Eher letzteres, oder?
Es muss auf jeden Fall ziemlich selten sein, denn sonst würden diverse HDD-Checks (ich checksumme in allen meine Backups alle Dateien, und die Daten dafür laufen ja logischerweise auch früher oder später durch den RAM für das Generieren der Checksum; anschließend wird der Kram alle paar Monate bis Jahr auch mal auf Korrektheit überprüft und dafür erneut im RAM durchgenudelt; sprich da habe ich bzw. haben meine beiden Notebooks über die letzten Jahre bestimmt mehrere Dutzend Terabyte*⁾ processed) bei mir auch hin und wieder fehlschlagen - nicht, weil die HDD unbedingt malfuncted und wirklich ein Festplattensektor unkorrigierbar verloren gegangen ist, aber weil irgendwas im RAM geflipped ist, und es den Anschein hatte, dass die Festplatte der Urheber ist.

Ich kann mich aber gerade an keine "unheimlichen Ereignisse dieser dritten Art" erinnern... (ok, vielleicht haben auch die MIB mein Gedächtnis gelöscht, man weiß ja nie )


____
*⁾ Bzw. Terrabyte, für die Gärtner unter den Lesern.

[Mit müden Augen]

ok, vielleicht haben auch die MIB mein Gedächtnis gelöscht, man weiß ja nie

Du meinst die MIB haben ein par Mebibyte in deinem Gehirn gelöscht?

Sorry für OT.

[The Poet]

ok, vielleicht haben auch die MIB mein Gedächtnis gelöscht, man weiß ja nie

Du meinst die MIB haben ein par Mebibyte in deinem Gehirn gelöscht?

Sorry für OT.

Ja. Und ersetzt haben sie die MIB durch einen BLOB. (Nein, nicht so einen Blob. So einen ^^.)

[halbkaputt]

D.h. deine bzw. die von dir implizit vorgeschlagene Theorie wäre: Beim alten System (vorm Wechsel zum aktuellen Angebot, betreut von Kolinatan) war die Dimensionierung der Hardware schlichtweg nicht groß genug für die Foren-Nutzungs-Peaks?

das ist nicht nur eine Frage von Größe. in richtiger Server Hardware(die für das Rootservergeschäft zu teuer ist) kommen noch ein paar andere Dinge dazu wie z. B. SAS vs SATA vs. NVME oder ECC vs non-ECC RAM. um mal ein Beispiel aufzumachen: Bit im Speicher in dem das gerade empfangene TCP Segment ist kippt. mit ECC wird das praktisch ohne Verzögerung korrigiert! bei NON-ECC muss erst die Checksummenkalkulation durchlaufen und fehlschlagen, damit der TCP/IP Stack das Paket nochmal anfordern kann bis der retry der Gegenseite im Speicher ist, ist schon 2x eine round trip time vergangen

Ok, wie oft kommt sowas vor, statistisch gesprochen? Ein one-in-one-thousand oder eher ein ≤one-in-one-billion-Ereignis? Eher

Wikipedia dazu:

Work published between 2007 and 2009 showed widely varying error rates with over 7 orders of magnitude difference, ranging from 10−10 error/bit·h (roughly one bit error per hour per gigabyte of memory) to 10−17 error/bit·h (roughly one bit error per millennium per gigabyte of memory).[

aber darum geht's auch nicht. es ging darum, dass "echte"(teure) Serverhardware besser ist - und das in vielfacher Hinsicht ECC war nur ein Beispiel. bei Mietrootservern wird oft nur einfache Consumerhardware benutzt, die so etwas nicht unterstützt. bei Hetzner weiß ich es gesichert(zumindest in den alten Rechenzentren. vielleicht sind sie da inzwischen aber von weg, weil man das letztlich mit teurem Personal zahlt, das hinrennen muss wenn öfter etwas ausfällt) und um ein anderes Beispiel anzuführen: selbst heute machen die heutigen mechanischen Serverplatten wesentlich mehr IOPs als Consumerplatten(von Dingen wie Resistenz gegen Vibrationen im Rack bzw. in der Verlängerung dann im Serverchassis will ich gar nicht erst anfangen)

[Kolinatan]

Es war kein "Home"-Server unterm Schreibtisch, sondern bei Hetzner.

Ok. Dann nehme ich mein Statement zurück. Dann ergibt der Schluckfauf Null Sinn.

Der größte Unterschied ist, dass der Webspace mit dem Webserver, jetzt auf einem eigenständigen Server läuft. Die Datenbank liegt jetzt auf einem eigenständigen Server. Daher können Änderungen an der Datenbank unabhängig von den Anfragen an den Webserver verarbeitet werden. Während dies für die CPU-Kapazität in der Regel keine Rolle spielen dürfte, kann die I/O-Kapazität der Festplatten relevant sein. Hierbei ist auch zu berücksichtigen, dass im Moment die Volltextindizierung nicht aktiv ist. Ein Update auf einen Volltextindex - was beim Posten einen Beitrags der Fall ist - kann ggf. zu einer aufwendigen Schreibaktion führen, je nachdem ob dieser in größerem Umfang umstrukturiert wird.

[Kolinatan]

Was auch schon deshalb keinen Sinn ergibt, weil ja angeblich die Suche "abgeschaltet" ist ...

Die Suche ist nicht abgeschaltet, sondern die Volltextindizierung von Beiträgen. Der Index ist aktuell fast leer (ein Beitrag ist indiziert). Daher funktionieren die andern Suchfunktionen - welche ohne die Indizierung auskommen - weiterhin.

[Ferienhaus]

Ich habe mal die letzten Seiten überflogen und bin mir nicht ganz sicher, ob die Frage schon gestellt wurde. Daher stell ich sie trotzdem rein.

Ganz blöde Frage:

Wenn ich früher, also vor dem Betreiberwechsel, beim großen Suchfeld oben Rechts den Namen eines Nutzers eingegeben habe, wurden mir scheinbar alle Beiträge angezeigt, in dem betreffender Nutzer zitiert/erwähnt wurde und - wenn ich mich nicht irre - meistens sogar viele/einige Beiträge des betreffenden Nutzers selbst.

Das war ein schnelles und probates Mittel an Beiträge irgendeines Users dranzukommen oder an dessen Profil , ohne ihn in der Mitgliederliste zu suchen oder gleich an Themen von Interesse. Für mich war das immer die deutlich schnellere und praktische Lösung für die Nutzung des Forums.

Jetzt scheint es aber so zu sein, dass die einfache Suche oben gar nichts mehr ausspuckt. Wenn ich meinen eigenen Nutzernamen oben eingebe - kommt nichts. Wenn ich andere Nutzernamen (bspw. "Kolinatan", "Tania") oben eingebe - kommt nichts. Und scheinbar selbst Begriffe wie "Beruf" oder "Trennung", bei der man davon ausgeht, sie würden in Beiträgen häufig erscheinen - kommt nix.

Funktioniert die Suche gar nicht mehr? Oder habe ich da irgendeine Einstellung nicht mitbekommen. Wenn ja fände ich das sehr schade, da ich einen Großteil meiner Forumsnutzerei während aktiver Zeiten eh immer über die Suche oben durchgeführt habe. Es ist schnell, einfach und bequem und ich würde schätzen, ich bin nicht der Einzige, dem es vielleicht so gehen könnte.

Kann man da was machen, wird da noch was gemacht oder stehe ich total auf dem Schlauch?

[halbkaputt]

Kann man da was machen, wird da noch was gemacht oder stehe ich total auf dem Schlauch?

Kolinatan hat das hier alles erläutert
@Kolinatan: da da jetzt schon ein paar Mal gefragt wurde: gibt phpBB das irgendwie her, dass man die Suchfunktion mit dem Post verknüpft? evtl. über das CSS? ich glaub das wäre schöner als es so "halb funktional" zu haben (im Sinne von: keine Fehlermeldung)