Lange Zugriffszeiten auf dem Server [php Problem?]

[Wolkenbruch]

Vielen Dank für die ausführliche und verständliche Antwort. Habe jetzt die Änderungen in der .htaccess wieder Rückgängig gemacht und die gzip Kompression aktiviert. Morgen, heute ist es einfach schon zu spät, begebe ich mich an die Abschaltung der Extensionen. Nochmals vielen Dank und Gute Nacht.

[Melmac]

Hi,

beim Deaktivieren der Extensions würde ich mit der "Avatar on last post" (?) beginnen und es erst einmal ohne sie probieren.

[Wolkenbruch]

In der Nacht hatte ich Zeit und habe alle Extensionen deaktiviert. Der Zeitgewinn bis zum Aufbau des Forums war minimal. Ich bin nun dabei alles was ich nicht wirklich brauche vom Server zu löschen. Der Provider, den ich konsultiert hatte, hat sich gemeldet. Seine Antwort will ich nicht richtg glauben, denn es gab Zeiten da war das Forum schnell wie ein Blitz und soooooo groß ist es nun auch nicht.

Hier die Antwort, vielleicht kann mir der eine oder andere dazu einen Tipp geben.

in der Tat beanspruchen sie auf dem Webserver mitunter die meiste CPU-Last für die Berechnung ihres Forums. Die Serverlast selbst ist jedoch innerhalb des grünen Bereiches. Für ihr Forum wird viel berechnet. Bei mir wird die Seite jedoch schon unter 4 Sekunden komplett aufgebaut, mehr geht leider nicht auf dem Shared Webserver. Dafür ist ihr Forum bereits zu groß geworden

[gn#36]

Völlig abwegig ist das nicht.

Du hast, zumindest bei der aktuellen Stichprobe, über 30 Nutzer gleichzeitig. Sehr klein ist das nicht, auch wenn es vielleicht nicht extrem riesig ist. Wenn man davon ausgeht, dass die sich in etwa 1 Seite pro Minute ansehen, dann ist das eine Seitenanfrage pro 2 Sekunden. Für jede davon gehen schon mal 0.7 Sekunden Vollzeit für die Berechnung der Seite ansich drauf. Jeder Aufruf generiert noch mal 30-40 Anfragen für Bilder, Javascript, CSS u.ä.. Vermutlich ist das Verhalten nicht so einfach zu beschreiben, denn beim ersten Laden greift der Cache des Browsers noch nicht, außerdem navigieren deine registrierten Benutzer vermutlich nach dem Erstzugriff viel schneller von der Startseite weg als ein Gast.

Ich glaube schon, dass das mit shared hosting gehen sollte, aber bei dem Paket, das du aktuell gebucht hast sind möglicherweise zu viele Kunden auf einem Server. Wenn z.B. 100 Kunden auf einem Server mit 10 Cores sind (wird es so nicht geben ist aber schön einfach zu rechnen), dann hat jeder Kunde in etwa pro Sekunde 100 ms Rechenzeit auf einem Kern. Um auf deine 0.7 Sekunden Vollzeit zu kommen wären also 7 Sekunden nötig. Wenn nur 50 Kunden auf dem selben Server wären steht die doppelte Rechenzeit zur Verfügung und du brauchst nur noch 3.5 Sekunden. Wenn wir noch mal davon ausgehen, dass du etwa eine Anfrage pro zwei Sekunden abarbeiten musst, dann wäre das bei der Rechenzeit aber immer noch zu viel.

Das ist natürlich alles stark vereinfacht betrachtet (insbesondere werden die anderen 99 / 49 Kunden vermutlich auch nicht dauerhaft die gleiche Leistung abrufen, so dass du zwischendurch mal mehr Leistung haben wirst).

Noch eine Idee, was du tun könntest: Verschiedene PHP Versionen laufen teils unterschiedlich schnell. PHP 5.6 dürfte z.b. üblicherweise schneller sein als PHP 5.3, wobei das aber auch noch davon abhängig ist, wie es eingebunden ist. Skriptlaufzeit reduzieren dürfte dir aber helfen, vielleicht solltest du da mal ausprobieren was geht.

Außerdem solltest du auf jeden Fall den Debug Modus, falls er aktiv ist, deaktivieren. Das kann phpBB ggf. deutlich beschleunigen. Das "Rekompilieren veralteter Stylekomponenten" solltest du ebenfalls deaktivieren, geh einfach die Serverlast Einstellungsseite mal durch.

[Wolkenbruch]

Vielen Dank für die sehr ausführliche, vor allem jedoch für mich verständliche Erklärung.
Auf dem Shared Webserver läuft php 5.3.10. Den Debug Modus habe ich nun deaktiviert. Das "Rekompilieren veralteter Stylekomponenten" war nicht aktiviert. GZIP Kompression ist aktiviert.
Es scheint, als wenn der Zugriff durch das Abschalten des Debug Modus schneller geworden wäre. Auf jeden Fall werde ich alle nicht unbedingt benötigten Erweiterungen entsorgen. Nochmals ein dickes Danke für die Antwort, denn sie hat mir geholfen die Problematik des "Servers" zu verstehen.

[Scanialady]

Vielen Dank für die ausführliche und verständliche Antwort. Habe jetzt die Änderungen in der .htaccess wieder Rückgängig gemacht und die gzip Kompression aktiviert. Morgen, heute ist es einfach schon zu spät, begebe ich mich an die Abschaltung der Extensionen. Nochmals vielen Dank und Gute Nacht.

Nur mal eine Zwischenfrage zum Verständnis:

bewirkt die Aktivierung der Kompression nicht eher, dass die ganze Geschichte langsamer und CPU-lastiger wird? Ich habe gn#36 jedenfalls so verstanden, und im ACP unter Serverl und Domain steht doch auch "Dies kann den Netzverkehr reduzieren, wird aber auch zu einer Erhöhung der CPU-Last sowohl auf Server- als auch auf Benutzerseite führen. "

Ich hätte das nun so ausgelegt, dass man damit zwar Traffic spart (der zumindest für mich keinerlei Problem darstellt), dafür aber CPU-Last erzeugt.

[gn#36]

Kann man pauschal nicht sagen, genauso wie man nicht sagen kann, dass unkomprimierte Daten auf der lokalen Festplatte sich schneller lesen lassen als komprimierte. Oft stimmt sogar das Gegenteil und komprimierte Daten sind schneller, weil die dann direkt im Speicher dekomprimiert werden können und das schneller ist als die Lesegeschwindigkeit der Festplatte. Bei komprimierten Daten hat die Festplatte dann weniger zu tun, ergo geht's schneller. Aber bei vielen sehr kleinen Daten stimmt das so dann auch nicht mehr. Analog: Gzip Kompression erfordert etwas zusätzliche Rechenleistung, dafür wandert aber anschließend der Inhalt schneller über den Äther (in dem Fall ist der Transfer der Flaschenhals). In den meisten Fällen bringt es da was, die Daten zu komprimieren, manchmal vielleicht aber nicht (wenn es insbesondere an der Rechenzeit hängt). Unsinn ist die Kompression bei JPEG, PNG etc, denn die sind bereits komprimiert. Textdaten (wie z.B. html, CSS, Javascript) dagegen lassen sich meist auch mit schnellen Algorithmen, die im direkten Vergleich nur eine mäßige Kompression schaffen, sehr effizient packen.