1. Herzlich willkommen bei WPDE.org, dem grössten und ältesten deutschsprachigen Community-Forum rund um das Thema WordPress. Du musst angemeldet oder registriert sein, um Beiträge verfassen zu können.
    Information ausblenden

STRATO VServer Linux V40-32 | Serverantwortzeit

Dieses Thema im Forum "Webhosting-Provider" wurde erstellt von flipmode, 14. April 2020.

  1. flipmode

    flipmode New Member

    Registriert seit:
    2. August 2012
    Beiträge:
    3
    Zustimmungen:
    0
    Hallo,

    ich betreibe ein paar eigene Projekte auf Basis von Wordpress/WooCommerce, darunter befinden sich auch einige selbst entwickelte Plugins. Aktuell dachte ich, es sei an der Zeit sich einen VServer anzumieten um das ein oder andere Projekt welches lokal entwickelt wurde im Livebetrieb zu testen.

    Mir ist bekannt das WordPress nicht besonders Ressourcenschonend arbeitet, daher hatte ich mich bei Strato für einen dedizierten 8 Kerner mit 32GB RAM und unglaublichen 800GB SSD entschieden. Der Preis ist verführerisch günstig, zusätzlich gilt eine Vergünstigung -> für nur 1€ / für in den ersten drei Monaten.

    Nachdem der Server frisch aufgesetzt war, hatte ich mich mit Hilfe von Plesk entschieden eine Wordpress installation vorzunehmen. Die Installation ist also "nackt" ohne jegliche drittanbieter Plugins. Nach einigen Tests bemerkte ich immer wieder extrem lange Wartezeiten beim navigieren. Via Putty und "top" hatte ich mich überzeugt das mein VServer nicht im CPU Limit hängt oder der Speicher überläuft, die Auslastung liegt durchgehend bei max 0.1%.

    Die Antwortzeiten überschreiten teilweise 60 Sekunden ( Screenshot! ), im Durschnitt liegt die Antwortzeit bei etwa 18 Sekunden. Das ganze ist nicht reproduzierbar und tritt willkürlich auf. Der Strato-Support hat sich dazu noch nicht gemeldet, ich war heute für Stunden am überprüfen ob ich den Server auch wirklich korrekt konfiguriert habe und konnte keinen Fehler ausmachen. Sind die VServer bei Strato wirklich so maßlos überbucht oder könnte ich doch etwas übersehen haben?

    Grüße,

    Jürgen
     

    Anhänge:

  2. r23

    r23 Well-Known Member

    Registriert seit:
    9. Dezember 2006
    Beiträge:
    7.317
    Zustimmungen:
    582
    Läuft evtl. PHP als Modul im Apache? oder wie wurde PHP installiert und welchen WebServer verwendest du?

    Hier eine Anleitung
    https://kinsta.com/de/lernen/wordpress-beschleunigen/
     
    flipmode gefällt das.
  3. flipmode

    flipmode New Member

    Registriert seit:
    2. August 2012
    Beiträge:
    3
    Zustimmungen:
    0

    Das Projekt läuft mit PHP 7.2.24 unter FastCGI
    Betriebssystem: Ubuntu 18.04 LTS 64bit + Plesk Onyx

    Generell besteht das Problem das ich meinen Server teilweise während solcher Phasen nicht erreichen kann, auch Putty lahmt dann für 15 Sekunden oder länger. Login in Plesk rödelt auch teilweise für eine halbe Minute bis ich mal die Loginmaske sehe.

    Das System wurde durch ein von Strato bereitgestelltes Image aufgesetzt, also alles out of the box bis auf das switchen auf FastCGI.

    Wie bereits angemerkt kann man Zeitweise für Minuten nicht wirklich zuverlässig darauf zugreifen, dann klappt es wieder für kurze Zeit.

    Achja, ich mache kein Geheimnis daraus -> hier liegt das noch leere Projekt: https://dev.wjmedia.de/
     

    Anhänge:

  4. JABA-Hosting

    JABA-Hosting Well-Known Member

    Registriert seit:
    29. März 2016
    Beiträge:
    2.988
    Zustimmungen:
    198
    Überlege doch mal warum der "Server" so günstig ist? Die Preise kann man nur machen, wenn die Hardware überbucht wird. Auch Strato bekommt die Hardware nicht umsonst, um diese Preise anzubieten.

    Meistens ist nicht die CPU der Flaschenhals, sondern die Festplatte. Hohe I/O Werte machen deinen Server träge.

    Das v(Core) steht für virtuell. Das heißt dir werden zwar 8 Kerne zugewiesen, diese teilst du aber mit vielen anderen Kunden. Die Kerne sind nicht dediziert für dich.
     
    flipmode gefällt das.
  5. flipmode

    flipmode New Member

    Registriert seit:
    2. August 2012
    Beiträge:
    3
    Zustimmungen:
    0
    Das hatte ich natürlich überprüft...

    root@XXXXXXXXX:~# sync; dd if=/dev/zero of=testfile bs=1M count=1024; sync
    1024+0 Datensätze ein
    1024+0 Datensätze aus
    1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 6,74426 s, 159 MB/s
    -----------------------------------------------------------------------------------------------------------
    root@XXXXXXXXX:~# dd if=testfile of=/dev/null bs=1M count=1024
    1024+0 Datensätze ein
    1024+0 Datensätze aus
    1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 0,33201 s, 3,2 GB/s
    -----------------------------------------------------------------------------------------------------------

    Die Schreibgeschwindigkeit ist natürlich nicht gerade der Burner, aber ich habe schon schlechteres gesehen.
    Heute z.B. läuft der Server glatt, gestern war Arbeiten unmöglich.

    Mir ist bewusst, das man zu diesem Preis keine Leistung eines "root-Servers" erwarten, aber Antwortzeiten von +30 Sekunden sind einfach nur lächerlich. Der Support hat sich nach 18h gemeldet ( kein Aushängeschild ) und versucht das Problem zu lokalisieren, mal sehen ob das gelingt.
     
  6. maltris

    maltris Well-Known Member

    Registriert seit:
    16. September 2012
    Beiträge:
    80
    Zustimmungen:
    2
    Die Vorredner haben recht, daher erhältst du auch von mir die klare Empfehlung, dich nach einem qualitativen Hoster von virtuellen oder dedizierten Servern umzuschauen. Viel Erfahrung in dem Bereich sagt mir, dass du bei deinem derzeitigen Anbieter, der ja doch recht bekannt ist, kaum auf einen grünen Zeig kommen wirst, zumindest mit deren virtualisierten Systemen.

    Wenn du dennoch daran festhalten möchtest, empfehle ich dir ein Performancemonitoring einzurichten, beispielsweise mittels collectd und einer entsprechenden Datenbank hinten dran, Check_MK oder anderen ähnlichen Hilfsmitteln. Hiermit wirst du dann sehen können wann und in welchem Ausmaß die Leistung degradiert wird. Schaue auch, ob zu diesen Spitzen dann eine besonders hohe IO-wait auftritt, iostat kann hierbei hilfreich sein.

    Eine weitere Verbesserung kann darin bestehen, von FastCGI auf FPM zu wechseln. Unter Umständen erfährst du hier ein wenig Performancezuwachs durch die etwas andere Art und Weise mit der FPM die Daten behandelt.
    Marginale Verbesserungen kannst duch auch nochmal durch ein Upgrade von PHP 7.2 auf 7.4 erreichen. Aber wie gesagt, wahrscheinlich alles wenig und marginal.

    Dein IO-Test mit dd beschränkt sich auf relativ große Blöcke (1M) und erfolgt mit Lese- und Schreibcache. Hier empfehle ich dir, den "direct" Modus zu probieren um direkt auf das Blockdevice "durchzuschreiben" und kleinere Blockgrößen zu testen. Im Thomas-Krenn-Wiki gibt es eine entsprechende Anleitung mit reichlich Erklärung.
     
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden