Reaktionszeit Server

  • Ich werde nicht schlau draus. Musste wegen eines Hardwareschadens den Server wechseln, leider. Der neue Server ist aber der bessere von beiden, also sowohl in Sachen CPU, RAM, SSD, als auch Netzwerk. Trotzdem sind (fast) alle Webseiten auf dem neuen Server deutlich langsamer.


    Die Konfiguration ist dieselbe wie vorher bzw. sogar noch mehr Ressourcen freigegeben. Da läuft auch nicht viel drauf, nur Apache und PHP. Die unten erwähnte "Datenbank" liegt jeweils auf einem externen Server, da hat sich beim Umzug nichts geändert.


    Geändert hat sich, gegenüber dem alten Server.


    CPU: 4x 2,6 GHz -> 6x 3,6 GHz

    RAM: 16 GB -> 64 GB

    Festplatte: SATA -> nvme SSD

    Netzwerk: 100 MBit/s -> 1.000 MBit/s

    PHP: 7.3 -> 7.4



    Seiten, generiert durch PHP - keine Datenbank:


    Da hat sich nichts verändert. Zugriffszeiten sind quasi wie vorher. Trotz mehr Leistung wurde da nix schneller, aber zumindest auch nicht langsamer.




    Eine Seite mit viel Datenbank (Domain liegt auf anderem Server):


    Die Domain nutzt den gleichen Datenbankserver wie alle anderen auch. Unterschied ist nur, dass die Webseite selbst auf einem anderen Server liegt. War vom Umzug also nicht betroffen. Nutzt alten Apache und alte Datenbank.




    Seiten mit PHP und viel Datenbank:


    Wie man sieht, hier ging es deutlich in die Knie.




    Seiten mit PHP und vereinzelt Datenbank:


    Die Seite nutzt zwar auch eine Datenbank, aber nicht bei jeder Anforderung. Nur eine Unterseite der Domain stellt eine Verbindung zu Mysql her.




    So, und daraus werde ich nun überhaupt nicht schlau. Was macht die Seiten nun so deutlich langsamer, wenn sie doch eigentlich schneller werden müssten? Gerade die, die sich deutlich verschlechtert haben, sind im Grunde 98% meiner Seiten.


    PHP wäre der erste Gedanke, schließe ich aber eigentlich aus, denn ALLE laufen mit PHP. Wenn es PHP wäre, müssten ja alle langsamer sein. Datenbank? Selbiges Spiel. Nicht alle mit Datenbank wurden langsamer, zumal die DB der gleiche Server ist wie vorher. Apache? Sieht aus wie PHP. Nutzen ja auch alle.


    Ich raff es nicht.

  • Hi Forumsfossil, Du bist auf dem richtigen Weg. Habe das Problem eigentlich schon gefunden, wollte aber noch 1-2 Tage warten, bis ich was dazu schreibe.


    Ja, es ist der Ping und zwar zur Datenbank, also die Verbindung da hin. Habe mich da leider selbst irritieren lassen. Vorher beteiligt waren zwei Rechenzentren, nun sind es drei. Wobei die drei von zwei verschiedenen Hostern sind.


    Die Domain aus dem zweiten Bild ist z.B. eine, die Hoster-intern agiert. Zwar zwei Rechenzentren, aber dennoch innerhalb des gleichen Hosters. Alle anderen liegen als Domain nun beim neuen Hoster, während die Datenbank noch beim alten ist.


    Und ja, Ping oder Laufzeit eben.


    RZ1 an RZ1 -> 0,0014 ms

    RZ1 an RZ2 -> 0,2 ms

    RZ3 an RZ2 -> 35 ms


    RZ1 und RZ2 sind der gleiche Hoster, RZ3 ist der neue. In RZ2 liegt die Datenbank. Somit sind auch die Zeiten klar, wenn die Webseite da 20 bis 25 Queries absetzt und die nun um die 35 ms benötigen.


    Habe die Datenbank nun von RZ2 ins RZ3 gezogen. Die Zeiten scheinen sich zu normalisieren. Wobei ich nun ein anderes Problem habe, denn es gibt einen Bug bei MariaDB 10.5., wenn auf dem Server Nvme-SSD läuft. Sprich, alle Queries in MariaDB 10.5. auf nvme sind langsamer als bei MariaDB 10.1. auf SATA.

  • Mit diesem neumodischen MariaDB kenn ich mich nicht aus; ich mach nur MySQL :) Ich weiss nicht wie gut sich das uebrtragen laesst.


    Je nachdem wie gut du in deinem CMS drinnensteckst, kannst du auch langsame oder aufeinanderfolgende queries so umschreiben dass du insgesamt weniger queries absetzt.

    In MySQL kannst du auch mehrere queries mit ; trennen und in einem rutsch uebertragen, sodass du weniger trips machen musst und insgesamt weniger latenz hast.


    Wenn das alles nichts hilft kann man entweder ein file-basiertes CMS nutzen, einen frontend-cache davorsetzten der die komplette .html zwischenspeichert.

  • Danke Forumsfossil. Das mit den Queries habe ich soweit schon immer durch. Kombiniert ist alles was geht. Im Gegenteil, bin nun eher dabei die wieder zu trennen, denn das wurden teils Monster. Und MariaDB arbeitet seit Version 10.5. völlig anders als MySQL, was den Optimizer betrifft. Bis 10.1. war das noch zu 99% gleich, aber jetzt? Queries, die vorher einen Index oder eben WHERE als Bedingung nutzten, lösen jetzt einen FULL-Scan aus.


    Der Bug ist was ganz anderes, das ist quasi eine extra Baustelle. Da werden wohl nahezu endlos irgendwelche Logs geschrieben, Bit für Bit, gelesen, geschrieben etc, hundert- und tausendfach, bis die Query endlich mal ausgeführt wird. Ist angeblich seit Version 10.8. behoben, aber nur in dem Sinne, dass die Logs nun "seltener" geschrieben werden.

  • Hm; also bei MySql gibt es den befehl "EXPLAIN ($beliebige query die lange dauert)" um zu schauen welche tabellen bei der abfrage geoeffnet werden, ob ein nutzbarer index dabei ist und wieviele eintraege dabei je tabelle verarbeitet werden muessen. Danach habe ich dann die indexes gesetzt, oder ggf. umgeschrieben. Wenn man indexes vergisst oder sie bei einem DBDump verloren gehen und 2 table mit je 2000 eintraegen hat, kann man auch pech haben und MYSQL durchsucht 4 Millionen moegliche kombinationen nach treffern.


    Ich habe in den letzten jahren fast nur noch Laravel genutzt. Damit erzeigt man zwar mehrere (einfache) queries als mit handgeschriebenem SQL, aber der code is sauberer, ueberschaubarer und wiederverwendbarer als vorher wo ich echt alles in eine query gesteckt habe.

  • Hm; also bei MySql gibt es den befehl "EXPLAIN ($beliebige query die lange dauert)" um zu schauen welche tabellen bei der abfrage geoeffnet werden, ob ein nutzbarer index dabei ist und wieviele eintraege dabei je tabelle verarbeitet werden muessen. Danach habe ich dann die indexes gesetzt, oder ggf. umgeschrieben.

    Jaja, so mache ich das ja auch. Die eine besagte oder schlimmste Query läuft bei MariaDB 10.1. mit 0,82 Sek durch. Bei MariaDB 10.5. in 14,2 Sek. Und ja, der Explain ist völlig anders. Joins und Subqueries werden da komplett anders ausgewertet. Indexe die da sind, teils nicht genutzt etc. Und da gibt es sogar eine Doku zu, was MariaDB 10.5. nun anders macht als MySQL 8 und das wird dort sogar noch als Vorteil beworben. Mag sein, für 0815 Queries, aber nicht für solche, die schon hoch optimiert waren.


    Und das ist ne Query, da sind an die 20 (Left)-Joins, Subqueries, Date-Ranges, Exists und "not exists" etc. drinnen.


    Daher mache ich das nun auch eher wieder mit der Aufteilung. Debugging der Monster-Queries ist fast unmöglich.

  • Was man bei Mysql in dem falle machen kann:

    - irgendwo tief in der MySQL doku gibt es auch befehle, womit man erzwingen kann welche indexes genutzt werden sollen.

    - teilweise kann man der config das "neue" verhalten irgendwelcher features wieder abstellen um kompatibel zu bleiben.


    Ich habe mal stundenlang gesucht warum irgendwelche einfachen additionen falsch waren, und am ende gab es eine einstellung wo je nach version bei "x+null" entweder x (alte version, war im frontend richtig) oder null (falsch, neue version) rauskam.