Ist mein Server zu schwach oder ist das ein Webseiten Problem?

Benjo

Benjo

New Member
Hallo,

ich betreibe eine WordPress-Website mit ungefähr 4 Millionen Nutzern pro Monat und 15 Millionen Google Analytics Sitzungen.

In den letzten Wochen habe ich ein Problem festgestellt, bei dem die Seite langsam wird und gelegentlich nicht erreichbar ist.

Interessanterweise wird die Seite wieder vollständig zugänglich und läuft mit normaler Geschwindigkeit, wenn ich den "Under Attack"-Modus von Cloudflare aktiviere.

Jedoch kehrt die Seite nach einigen Stunden ohne den "Under Attack"-Modus zu ihrer normalen Zugänglichkeit und Geschwindigkeit zurück.

Mein Hosting-Anbieter meint, dass wir möglicherweise zu viele gleichzeitige Zugriffe haben oder ein problematisches WordPress-Plugin vorliegt.

Die Website verwendet WP Rocket Caching und ist für Geschwindigkeit optimiert.

Ich versuche, das Problem zu ermitteln.

Ist mein Server mit diesen Spezifikationen in der Lage, diesen Traffic zu bewältigen? Oder könnte dies auch durch ein WordPress-Plugin verursacht werden?

Wie kann ich das herausfinden?

Wir sind auf einem Managed Server gehostet mit:

  • Intel® Xeon™
  • 4 Prozessorkerne (8 mit Hyper-Threading)
  • 64 GB RAM
  • 2 TB SSD (RAID 5)
 
Welche Art von Monitoring hast du denn am Laufen? Und was überwachst du?
Schom um zu sehen ob z.B. viele Networkzugriffe dann die Datenbank deiner Wordpress-Site belasten o.ä.
 
Additiv dazu: auf welchem Techstack laeuft das WP? Kannst du das Verhalten in den einschlaegigen Logs nachvollziehen bzw. ein Muster erkennen?

"Gelegentlich nicht erreichbar" ist HTTP 504 oder wirklich hart Connection Refused?

Ansonsten ist noch interessant was fuer ein Request Pattern du hast, mehr statische oder mehr dynamische Inhalte (also ggf. ein Problem schon beim Rendern oder erst beim Ausliefern).
 
Der Server (die Hardware) hat damit null Probleme, die schafft locker mehr als das Zehnfache an Connections.

Es ist also ein Software-Problem und da kommt jegliche beteiligte Software in Frage. Angefangen beim OS, weiter zur DB, weiter zum Webserver, weiter zu PHP, weiter zu WP, weiter zu jeglichen WP-Plugins, weiter zu jeglichen PHP-Extensions, usw. usw...

Und ja, WP-Plugins (inklusive diverser "Cache"-/"Optimierungs"-Plugins) und WP-Themes sind immer die ersten Kandidaten für die Fehlersuche...
 
19 Millionen Zugriffe pro Monat: Durch 30 Tage im Monat, durch 24 Stunden pro Tag, durch 60 Minuten pro Stunde, durch 60 Sekunden pro Minute: 7,33 Zugriffe pro Sekunde. Klingt erst mal nicht viel.

Wie viele Zugriffe macht der Webserver denn tatsächlich pro Sekunde? Ist das wirklich der Flaschenhals?

Edit: @Joe User war schneller :).
 
nexus said:
Dann tritt deinem Anbieter mal gehörig auf die Füße, damit er in die Gänge kommt und dein Problem löst. Er läßt sich ja bestimmt sehr gut für die managed Option bezahlen...
Click to expand...

Ich habe den Server bei All-Inkl gehostet. Ich habe Ihnen jetzt nochmal per Mail geschrieben.

Am Telefon waren Sie nicht auskunftsfreudig und haben einfach auf Cloudflare verwiesen? Weil ich Cloudflare zwischen den Server und meine Domain geschaltet habe.

Werde es nochmal per Mail jetzt probieren.
 
greystone said:
Es gibt ca. 500-1000 Prozessoren mit der Bezeichnung. Der Faktor des Leistungsunterschiedes vom Anfang bis zum Ende der Liste ist über 1000. Kannst Du das also näher spezifizieren?
Click to expand...

Sorry. Bin kompletter Noob auf dem Gebiet.

Hier:
4 Prozessorkerne
8 mit Hyper-Threading

Steht unter meinem Server CPU.
 
Joe User said:
Der Server (die Hardware) hat damit null Probleme, die schafft locker mehr als das Zehnfache an Connections.

Es ist also ein Software-Problem und da kommt jegliche beteiligte Software in Frage. Angefangen beim OS, weiter zur DB, weiter zum Webserver, weiter zu PHP, weiter zu WP, weiter zu jeglichen WP-Plugins, weiter zu jeglichen PHP-Extensions, usw. usw...

Und ja, WP-Plugins (inklusive diverser "Cache"-/"Optimierungs"-Plugins) und WP-Themes sind immer die ersten Kandidaten für die Fehlersuche...
Click to expand...

Interessant.

An wen sollte ich mich wenden, der so etwas überprüfen kann? Wie ist die Job Bezeichung für so eine Person?
 
Benjo said:
An wen sollte ich mich wenden, der so etwas überprüfen kann? Wie ist die Job Bezeichung für so eine Person?
Click to expand...
Hier im Forum gibt es den Bereich "Suche" -> https://serversupportforum.de/forums/suche.60/
Dort kannst du eine entsprechende Anfrage posten. Hier im Forum sind genug professionelle Admins unterwegs, die sich das (gegen entsprechende Bezahlung natürlich) anschauen und deine Kiste optimieren können.
 
nexus said:
Hier im Forum gibt es den Bereich "Suche" -> https://serversupportforum.de/forums/suche.60/
Dort kannst du eine entsprechende Anfrage posten. Hier im Forum sind genug professionelle Admins unterwegs, die sich das (gegen entsprechende Bezahlung natürlich) anschauen und deine Kiste optimieren können.
Click to expand...
Danke!

Sollte ich nach jemanden schauen der mein Wordpress Backend, PHP und Datenbank überprüft und optimiert? Oder soll ich nach jemanden schauen der auf der Server Seite schaut?
 
Benjo said:
Sollte ich nach jemanden schauen der mein Wordpress Backend, PHP und Datenbank überprüft und optimiert? Oder soll ich nach jemanden schauen der auf der Server Seite schaut?
Click to expand...
Am einfachsten wäre es, wenn du in deiner Anfrage auf diesen Thread hier werweist/verlinkst. Dann haben potentielle Auftragnehmer schon einen ersten Überblick und werden in der Kontaktaufnahme zu dir entsprechende Vorschläge machen, was ihrer Meinung nach zu tun wäre.
 
Benjo said:
Sorry. Bin kompletter Noob auf dem Gebiet.

Hier:
4 Prozessorkerne
8 mit Hyper-Threading

Steht unter meinem Server CPU.
Click to expand...

Das ist auch nicht die gewünschte Information. Wahrscheinlich ist das System virtualisiert und die CPU-Bezeichnung ist vom Hoster manuell auf diesen generischen - nichtssagenden - Wert gesetzt.
 
Die CPU ist doch völlig Wurscht, die paar Requests schafft selbst ein RasPi problemlos...

Wie ich bereits schrieb, zuerst alle WP-Plugins und WP-Themes deaktivieren (aka deinstallieren) und zwei/drei Tage beobachten ob es hilft.
1. Wenn ja, dann ein einzelnes Plugin/Theme wieder aktivieren und erneut zwei/drei Tage beobachten ob es knallt.
1.1. Wenn ja, dann auf dieses Plugin/Theme verzichten.
1.2. Wenn nein, dann mit dem nächsten Plugin/Theme wiederholen. GOTO 1.1
Damit sind ~95% aller Performance-Probleme bei WP-Installationen erschlagen.
Für die restlichen ~5% optimiert man PHP-FPM (aktuellste Version verwenden, unnötige Extension rauswerfen, Pool optimieren, etc.).
Wenn das nicht reicht, dann kommt die DB-Konfiguration dran, da lässt sich oft auch noch ein Wenig rausholen.
Nun käme der Webserver dran und danach das OS (Netzwerksettings, Netzwerktreiber, vermeintliche Security-Tools ala Fail2ban, Anti-Malware, etc.).
Ganz zum Schluss würde ein Hardware-Wwechsel anstehen, bis hierhin kommt es aber nur extremst selten...
 
@Joe User: Grundsätzlich Danke für die Schilderung Deines Ansatzes, wie Du da vorgehst. Ich gehe mal davon aus, dass Du das selbst so machst und das auch erfolgreich tust.

Allerdings verstehe ich nicht, wie das ein Ansatz bei einem Produktivsystem sein kann, einfach mal ein paar Softwarebausteine da zu deaktivieren? Es ist ja nicht so dass Plugins und Themes irgendwie optional wären, und man ein laufendes Produktivsystem mal eben so ein paar Tage ohne die laufen lassen kann. Die meisten sind da absolut essentiell. Nach einem deinstallierten Theme ist eine Seite nicht mehr nutzbar. Niemand kommt da mehr und wo soll da noch die Last herkommen, um da eine Überlast-Problematik testen zu können?
 
Die meisten (WP-)Themes sind lediglich optisch "gut", aber wenn man sich mal deren HTML/CSS/JS ansieht, wird einem schnell bewusst, dass das niemals performant gerendert werden kann und zusätzlich ist der Müll dann auch noch künstlich aufgebläht und verstopft unnötig die Leitung...
Das WP-Basistheme ist zwar auch noch weit weg von optimal, aber schon deutlich besser als das Gros der anderen Themes.
Daher macht meine Vorgehensweise durchaus Sinn und ist auch praxistauglich, denn bei der Request-Anzahl dürfte es sich kaum um "Stammuser" handeln, sondern vielmehr um Laufkundschaft und der ist das Theme völlig egal (Suchmaschinen übrigens auch).

Gleiches Prinzip gilt für die WP-Plugins: Fast Alle sind für den Betrieb der jeweiligen Website absolut nicht nötig und somit ist ein (temporärer) Verzicht auch nicht nachteilig.
Oder als Gegenfrage: Welches WP-Plugin ist denn so essentiell, dass man nichtmal temporär darauf Verzichten könnte?


Und wenn man das nicht Live erledigen will, dann nimmt man halt sein identisches Testsystem und debugged dort...
 
Last kann man beim testen natürlich mit z.B. apachebench selber erzeugen und gleich die Antwortzeit messen…
 
greystone said:
@Joe User: Grundsätzlich Danke für die Schilderung Deines Ansatzes, wie Du da vorgehst. Ich gehe mal davon aus, dass Du das selbst so machst und das auch erfolgreich tust.

Allerdings verstehe ich nicht, wie das ein Ansatz bei einem Produktivsystem sein kann, einfach mal ein paar Softwarebausteine da zu deaktivieren? Es ist ja nicht so dass Plugins und Themes irgendwie optional wären, und man ein laufendes Produktivsystem mal eben so ein paar Tage ohne die laufen lassen kann. Die meisten sind da absolut essentiell. Nach einem deinstallierten Theme ist eine Seite nicht mehr nutzbar. Niemand kommt da mehr und wo soll da noch die Last herkommen, um da eine Überlast-Problematik testen zu können?
Click to expand...
Es ist ja erstmal auch wichtig die Ursache zu finden. Wenns kein Staging oder Testing System gibt, dann muss eben Prod herhalten.

Wenn die Ursache bspw. ein zu fettes und unoptimiertes Theme ist, kann man da ansetzen. D.h. Theme wieder re-aktivieren und parallel was schlankeres suchen oder bauen (lassen).

Am Ende ists auch je nach Use-Case einfach eine Risiko-Bewertung. Wir hosten viel fuer/in Tourismus-Unternehmen, die nehmen zur Weihnachtszeit gerne einfach Features aus den Apps um dafuer die Responsezeiten hochzuhalten ohne gleich alle App- und DB-Cluster arg in die Breite zu ziehen. Da ist das Risiko auf ein paar kleine Features zu verzichten gegenueber einem Umsatzeinbruch weil "Seite ist ja mega lahm, dann geh ich zur Konkurrenz" recht einfach abwaegbar.
 
You must log in or register to reply here.
Back
Top