Woher kommen die extremen Ladezeiten?

Hallo Leute! Hallo WoltLab-Team!

Ich habe ein bekanntes Problem, dessen Ursache ich bisher nicht sicher eingrenzen kann: Die Ladezeiten der WBB-Seiten ist teilweise extrem lang. Wo phpBB bisher max 1 Sekunde braucht, lädt WBB teilweise 10-20 Sekunden.

Server:
zur Zeit "größter" Strato Linux Root vServer mit CentOS 7 + Plesk12
16 vCores 2,8 GHz
16-32 GB RAM
Bandbreite ? (ich finde die Angabe nicht)

Datenbank:
mysql / innoDB (klar hier) mit 1.700.000 Datensätzen, 44.000 User, 42.000 Themen, 250.000 Beiträge, komprimiert 130 MByte, entpackt ca. 690 MByte

Wie (auch von Anderen berichtet) gesagt, läuft das ganze mit phpBB sehr flüssig. Pro Tag sind ca. 10.000 bis 12.000 unique Visitors auf der Seite. Glaubt man der WBB-Statistik, so sind aktuell bis zu fast 800 Besucher (inkl. der anonymen + Bots) im 15-Minuten-Zählfenster auf dem vServer. Der Benchmark zeigt zwar teilweise auch hohe Sekunden-Werte an (4 bis 10 Sekunden oder so), aber oft zeigt er auch nur 0,25 Sekunden, obwohl die Netzwerkanalyse mit Firefox ganz klar die langen Wartezeiten von 10-20 Sekunden bestätigt. JavaScript wird scheinbar zum Teil nachgeladen, wenn die Seite schon angezeigt wird. Auffällig ist in der Netzwerkanalyse vor allem, dass für den HTML-Teil z.B. 8 Sekunden gebraucht wird obwohl der Benchmark unten am WBB für php und SQL deutlich weniger anzeigt (0,25 oder meinetwegen auch bis zu 3-4 Sekunden). Timeouts gibt es keine (php_max_execution 45 Sekunden).

Wo bleibt also die restliche Zeit? Bandbreiten-Limit? Wartezeit bis ein "Slot" von Apache freigegeben wird für die Berechnungen?

Da das importieren der Datenbank auf meinen zuvor genutzten (Managed Dedicated) Server, bedingt durch innoDB und "innodb_flush_log_at_trx_commit=1" (dort nicht veränderbar) so wahnsinnig lange dauert (30 Stunden) ist es schwierig um eine Gegenprobe mit dem anderen Server zu machen. Zumal Last sowieso erst auf das ganze System kommt, wenn ich den echten Besucher-Ansturm drauf los lasse.

Da der vServer theoretisch echte CPU-Resourcen zur Verfügung stellt und man sich dort "nur" Bandbreite + Festplatten/SSD-Speichersystem teilt, erwarte ich eigentlich bessere Leistung .

Ach ja, laut Plesk-Monitoring-Tool ist die CPU mit rund 25-35 % ausgelastet, wenn man 1/5/15-Minuten-Intervall anschaut. RAM wird max. nur rund 2,5 GByte belegt.

Leider sind Gegenproben mit anderen Servern immer gleich kostenintensiv, da man Einrichtungsgebühren bei den "echten" Root Servern zahlen muss (oder 12/24 Monate das Ding womöglich ohne bessere Performance am bein hat...). Ich kenne prinzipiell Eure Bedenken gegenüber bestimmten Webhostern und kann diese zum Teil auch bestätigen. Leider ist man z.B. bei Hetzner auch nicht bereit innodb_flush_log_at_trx_commit=2; einzustellen, sonst würde ich komplett bei einem Managed Server bleiben.

Ich hänge einen Screenshot an, der sowohl die Benchmark-Zeit als auch die Netzwerkanalyse zeigt. Wer hat ein vergleichbar großes Forum und kann mir helfen?

Gruß + besten Dank schon jetzt

N'Abend!

Ja, es handelt sich um das Thunderbird Mail DE-Forum unter www.thunderbird-mail.info (die bisherige Domain www.thunderbird-mail.de zeigt noch auf den "alten" Dedicated Managed Server mit altem Wiki). Durch die Performance-Probleme läuft die Seite zur Sicherheit vorübergehend zweigeteilt und ich habe noch nicht richtig an der Portierung der Inhalte außerhalb des Forums gearbeitet.

Die Mitarbeiter an der entsprechenden Hotline waren freundlich, konnten mir aber inhaltlich eher weniger helfen und haben sich zu keinerlei Aussage bewegen lassen, ob die Probleme eher an meiner Server-Konfig, dem Forensystem oder an der eigenen Hardware-Konfiguration liegen. Die machen sogar Aussagen, die den garantierten CPU-Resourcen des vServers widersprechen. Man sagte mir heute, dass die vServer KEINE garantierte Bandbreite für den Uplink haben - ich vermute da das Problem. Es ist für mich aber bisher ein Rätselraten. Daher wäre ich schon dankbar, wenn jemand bestimmte Ursachen sicher ausschließen könnte. Ich gebe gerne weitere Informationen, wenn Ihr konkret danach fragt. Wenn ein WoltLab-Supportler Zugangsdaten sinnvoll zum Nachschauen haben möchte, können wir auch darüber per Konversation reden.

Lizenz ist aus 11/2014.

Ok Danke, Ticket wurde erstellt.

Server heute früh testweise neu gestartet: wie erwartet kein Unterschied - leider

Der Server war heute von 04:00 bis 16:00 quasi nicht erreichbar, da ich (hüstel...) wohl Mist gebaut habe. Jetzt ist alles ist neu aufgesetzt. Betriebssystem gewechselt + PHP aktualisiert (läuft jetzt mit OPcache). Wenn also jemand sich ein Bild von den Ladezeiten machen möchte und mir mit weiteren Infos/Kritik/Ideen zur Problematik helfen kann, dann ist das jetzt wieder möglich.

Der Benchmark ist nur als Folge der langen Ladezeiten (und anfangs ganz massiv Timeouts) zu Testzwecken aktiviert - wenn auch über einige Tage.

Danke Euch allen für die Rückmeldungen. Danke auch an das WoltLab-Team: von Euch habe ich eine vernünftige differenzierte Rückmeldung erhalten (im Gegensatz zur Rückmeldung vom Webhoster...).

Das Problem ist nun behoben. Die Seite liegt nun (wieder) auf einem dedizierten Server.

Ich kann als Folge davon nur von Stratos vServer (auch dem "größten") mit "super tollem" (hüstel...) Speichersystem und keinerlei garantierter Bandbreite für den Uplink abraten. Die Ladezeiten waren unterirdisch - trotz identischer Konfiguration. vServer anderer Anbieter mögen vielleicht besser funktionieren, aber die Kombination aus fehlender Bandbreitengarantie und Schulterzucken des Webhoster-Supports, die behaupten, dass mein Support-Ticket zu pauschal sei (obwohl ich mehrfach am Telefon differenziert erklärt habe, hat man das Ticket scheinbar von deren Seite selbst zu pauschal angelegt), geht gar nicht.

Gruß + schöne Adventszeit