XF2.0 FcgidMaxRequestsPerProcess ?

Gut, DAS lasse ich dann doch besser meinen Bekannten erledigen ... von sowas lasse ich dann mangels Erfahrung doch die Finger. Wobei ich auch schon ca 6 Montate darauf warte, das der die MariaDB aktualisiert

Wobei mich das echt wundert alles.. wir sind mit der Domain vor ca 2-3 Monaten auf den neuen Server gezogen. Bis vor 2-3 Wochen lief wie gesagt alles perfekt.
Auch davor, auf dem "uralt" Server lief soweit alles rund... der Umzug kam eigentlich nur zustande, weil ich das ganze lieber getrennt von allen anderen Domains haben wollte.

Ich warte jetzt erst mal die nächsten 24 Stunden ab. Vielleicht hat dein Tipp mit dem FPM ja schon geholfen. Bis jetzt habe ich jedenfalls ein gutes Gefühl.

 

Das Problem, dass sich die Seite aufhängt, ist nun scheinbar wirklich weg
Vielen Dank!!!

 

Falls das Problem erneut auftritt, öffne nochmal deine Phpeinstellungen ,scrolle ganz runter und trage unter Zusätzliche Konfigurationseinstellungen Folgendes ein: FcgidBusyTimeout 1800
Das erhöht die Wartezeit bevor ein Request abgebrochen wird. In Plesk ist das auf einem Default von 600 eingestellt was bei stark frequentierten Seiten zu kurz sein kann.

 

Hm.. mal schauen.

Bislang tauchen seit der Umstellung auf FPM nun "nur" die zuletzt genannten Error/Apache Fehler in unregelmäßigen Abständen (stündlich oder alle paar Stunden) auf:

(22)Invalid argument: AH01075: Error dispatching request to: Example Domain
AH01068: Got bogus version 199, referer: Example Domain
AH01068: Got bogus version 190, referer: Example Domain
AH01068: Got bogus version 243, referer: Example Domain
AH01068: Got bogus version 82, referer: Example Domain
AH01068: Got bogus version 112, referer: Example Domain
AH01068: Got bogus version 150, referer: Example Domain
AH01068: Got bogus version 180, referer: Example Domain
AH01068: Got bogus version 47

Blöderweise liefern all diese Fehler keine konkrete Datei aus wie bei anderen Error Meldungen, sondern immer nur die Haupt-URL. So das man leider nicht eingrenzen kann, welche Funktion/Aktion die Fehler auslöst.
Da diese aber scheinbar keine Auswirkungen auf die Performance haben (zumindest merkt man es nicht) lasse ich von weiteren Konfigurationen mangels Ahnung erst mal die Finger.

 

Nö - generell schon mal gar nicht.

 

Menno!!!

 

Diese Fehler treten auf wenn Scripte keine Daten ausgeben und/oder einfach (mangels Daten) abbrechen.
Kannst du also Ignorieren.

Übrigens ist ein Proxy in Sachen Performance nicht unbedingt besser, bei mehrheitlich dynamisch erzeugten Daten kann der sogar das Gegenteil bewirken.
In Sachen statische Inhalte ist NGinx dann wieder Vorteilhaft

 

Drum kann mans ja auch so schön kombinieren und dazu dann ggf. verschiedene Caches benutzen.

Im Xenforo wird fast alles dynamisch erzeugt - aber bei vielen Seiten macht es schon sehr Sinn, auch dynamische Inhalte zu cachen. Wichtig ist hier dann aber die optimale Cache Haltezeit zu finden.

Beispiel: eine Seite des Forums mit den Beiträgen eines Themas.
Ist ja erstmal eine klassische dynamisch erzeugte Seite.
Nun kommen in den seltensten Fällen tatsächlich jede Sekunde Änderungen an dieser Seite.
Hier macht es mMn. nun schon sehr wohl Sinn, diese Seiten auch zu cachen, aber eben mit relativ kurzen Cache Haltezeiten.
Warum? Greift nur ein Nutzer jede Minuten darauf zu - ok, macht das cachen weniger Sinn oder man könnte die Haltezeit hoch setzen. Was aber wenn man ein gut besuchtes Forum hat? Wenn z.B. jede Sekunde mehr als ein Nutzer auf den dynamisch erzeugten Inhalt zugreift? Genau da macht das cachen von dynamischen Seiten sehr wohl richtig Sinn.

Von daher gibt es aus Forum-Sicht nur wenige dynamische Seiten, die nicht von einem Cache/gecachten Proxy profitieren würden. Siehe auch Empfehlungen seitens Xenforo oder Wordpress - beides klassiche dynamisch erzeugte Seiten.

 

Für Gäste mag ein Caching (mit einer kurzen TTL) noch gehen, für registrierte Nutzer ist es (ohne massive Umbauarbeiten) praktisch kaum möglich

... und da wird es bei Foren richtig, wichtig schwierig:
Hast Du ein CMS/Blog mit ein paar (hundert) Seiten die oft aufgerufen werden ist Caching leicht.
Aber bei einem Foren mit Millionen von Beiträgen verteilt über einige hunderttausende URL wird es haarige wenn eine URL vielleicht ein paar mal/Monat aufgerufen wird - was willst Du da cachen?

Da bräuchtest Du vmtl. kleines Forum viel Traffic damit das funktioniert, aber wenn selbst hochfrequentierte Threads nur alle paar Minuten mal aufgerufen werden ... hast Du kaum eine Chance.

Daher sehe ich da kaum Potenzial, wie gesagt bei einem WordPress mit wenigen Seiten aber viel Traffic (pro Seite) sieht das ganz anders aus.

Kleines reales Zahlenbeispiel (Traffic eines Forums in einem Monat)
9,2 Millionen Seitenaufrufe die sich auf ca. 690.000 URL verteilen (Analytics-Rohdaten; wenn man die normalisieren würde wäre es sicher eine ganze Ecke weniger, spielt für die Größenordnungsbetrachtung aber keine Rolle).

Die Top 15 URL kamen dabei auf Werte zwischen ca. 13 und 25K Seitenaufrufen (insgesamt 314 K).
Im Schnitt wurden diese Seiten also ca. alle 103 bis 199 Sekunden einmal aufgerufen.

Daher verweise ich mal auf dein vorheriges Zitat:

Bei diesem Beispiel müsste man für min. 2-5 Minuten cachen um überhaupt einen Effekt zu sehen - und hätte dennoch nur ca. 3% des Traffics abgedeckt, wollte man mehr abdecken würde die Cache-Dauer schnell rapide ansteigen.

Und da in den Zahlen auch Registrierte Nutzer enthalten sind, sind die Werte nur für Gäste (denn wir gesagt, für RegUser ist das praktisch aussichtslos) mit Sicherheit noch schlechter.

Summa Summarum: Cachen von (aggregierten) Daten, ja - unbedingt
Cachen ganzer Seiten hingegen ist bei einem Forum schwierig bis unmöglich.

 

Ja, das mit dem Cachen ist so eine Sache. Da braucht es Erfahrung und Benchmarking.
Manche Seitenbetreiber cachen sich ihre Präzenz regelrecht langsam.
Zuerst einmal ist Hardware/Ram/Proz/HDD, besser SSD, wichtig. Dann möglichst vieles
der Datenbank im Arbeitsspeicher halten und einen PHP-Cache im Hintergrund.
Dann ist auch bei größeren Foren oder WP-Präsenzen ein NGinx unnötig.

 

Gibts eigentlich schon Server die auf M2 SSDs setzen? Ich mein, das würde dann womöglich manche heute noch gültige Ram/Cache Regel über den Haufen werfen ob der Übertragungsraten. SSD, da hast du völlig Recht, ist für eine potente DB wirklich ein probates Mittel der Wahl, schon der deutlich höheren I/O wegen.

Danke, endlich mal einer der NGinx nicht als Allheilmittel ansetzt. Volle Zustimmung.

 

Oh ja. Frage eines erstaunten (Ex) Forenbetreibers nach der Übernahme eines Projekts durch uns:
"Was habe ihr gemacht dass das auf einmal so schnell ist, was für Sever habt ihr?"
Meine Antwort: "Ich habe die ganzen Optimierungs Add-ons (Anm. er hatte gleich mehrere parallel im Einsatz ) entfernt und die wirklich wichtigen Stellschrauben korrekt eingestellt"
Leider wird hier oft nach dem Motto "viel hilft viel" ohne Sinn und Verstand agiert

CPU (Kerne, Tanktfrequenz) ist gar nicht mal soo entscheident, nur sollte es eine richtige Server-CPU sein mit entspchen dicken L2/L3-Caches - Server mit Conumer-CPU ala Hetzner Intel Core iWasweißichwas kann man unter richtiger Last knicken.
Zumindest Datenbanken sollten nur auf SSD

Absolut korrekt. Gibt da einen schönen Spruch dem IMHO viel Wahrheit inneliegt:
Es gibt nur eine Sache die RAM bei Datenbanken ersetzen kann: mehr RAM.
Unsere DB-Maschinen haben daher min. 128 GB, das reicht zwar nicht für alles aber zumindest für das was warm ist.

Gibt esvmtl., wird sich aber wohl nicht durchsetzen, ist eher was für den ProSumer/Mobile-Bereich - für Server ist eher U.2/SFF-8639 angesagt.
Wobei "M2" alleine eh nichts aussagt - das kann auch SATA sein und da hat man dann (außer halt einem anderen Format) eigentlich keinen Vorteil gegenüber ner klassischen 2,5" SATA (AHCI) SSD

 

Ich hatte mir vor 3 Wochen da auch einiges zu angelesen. Die Unterschiede sind gewaltig.
Hier mal ein Beispiel - man beachte die Lese-/Schreibzeiten in der übersicht:

Ihre Suche auf ALTERNATE.de

Für die, denen da ein wenig die Grundlagen fehlen:

M.2 SSD: Vergleich, Empfehlung, Kauftipp | ssd-ratgeber.de

LG: Tammy

 

Ich meinte schon richtige M.2 SSDs mit Datenraten um die 2-3 GB/s. Ja, U2 hatte ich doch glatt unterschlagen. Im Kunsumer Bereich kenn ich kaum sinnvolle Anwendungsfälle, wo eine gute M2 SSD einer guten SATA SSD merklich überlegen ist. Wir haben mit solchen Setups einige Tests während der Umschulung gemacht und unterm Strich konnte man sagen, außer beim Start und beim kopieren wirklich großer Datenmengen (Stichwort UHD Videos z.B. ) hatten die M.2 kaum wirklich gravierende Vorteile. Interessant wäre halt, wie die sich in einem Server schlagen würden der ob der wesentlich mehr zugreifenden Nutzer die Datenraten und I/O wohl besser auslasten könnte. U.2 dito.
Gibts dazu schon irgendwelche Tests?

 

Was machst du am PC, bzw. Otto-Normal? Surfen, Videos gucken, Office ... da bringt dir die M.2 kaum bis keine spührbaren Vorteile, da entweder nicht so große Datenmengen gefordert sind oder die restliche Hardware diese nicht schnell genug verarbeiten kann (Prozessor, Ram, wmgl. eine weitere normale SSD oder HDD gar). Wie zuvor schon gesagt, seh ich den Hauptvorteil in der deutlich höheren Datenrate - die man aber auch erstmal auslasten muss. Otto-Normal schaft das seltenst.

Wie gesagt, mich tät mal interessieren, wie das aug Server-Ebene ausschauen könnte und tut.

 

Das ist wohl wahr... wenn man aber zb viel mit der Adobe Cloud etc arbeitet, ist es schon ein großer Vorteil.
Habe mir den hier vor 1,5 jahren gekauft Zen AiO Pro Z240IC | All-in-One PCs | ASUS Deutschland und kann seit dem endlich flüssig arbeiten ohne ständig fluchen zu müssen *gg
Jedenfalls für mich reicht es (endlich).

Hmmm... beim Server... da werde ich dann wohl irgendwann noch mal nachlegen müssen, wenn ich das hier so lese, dass scheinbar 500 GB SSD und 6GB RAM nicht ausreichen
Da aktuell noch nicht so viele tägliche Besucher (ca 300) auf das Forum zugreifen, ist es aber wohl alles erst mal okay.

 

Klär mich doch mal bitte auf, was eine M.2 mit der Cloud zu tun hat, Ich dachte bisher immer meine Internetanbindung ist der limitierende Faktor oder halt der Server den ich aufrufe. Aber die 600 MB/s die eine SSD bringt, sollten für eine Cloud Nutzung wohl mehr als ausreichend sein - oder hast du eine GB-Internetanbindung?

 

Die "GB-Internetanbindung" die 600 MB/s schafft würde ich gerne mal sehen

Bei SSDs kommt es für gewöhnlich auch weniger auf die Transferrate an als auf die IOPS; ob da nun 80 MB/s übertragen werden können oder 600 MB/s - wenn man nicht ständig mit riesigen Dateien hantiert spielt das kaum eine Rolle.
Aber ob ~ 100 oder einige Tausend IOPS durchgeführt werden können, das merkt man sehr wohl.

 

Darauf sollte es anspielen.

Volle Zustimmung zum Rest.