XF2.x 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.