Scriptlaufzeiten, extreme Schwankungen

  • Hallo,

    ich habe mit meinem Webspace (4000er) das Problem das sich seit einigen Wochen die Scriptlaufzeiten stark verändert haben.

    Dabei wird ein und dasselbe Script mit identischer DB genutzt und es kommt zu Laufzeiten von 51ms bis zu über 12000ms(!).

    Solch extremst unterschiedliche Zeiten kenne ich nicht bei ein und demselben Script.

    Das Script läuft nun schon seit einigen Monaten (unverändert) und führt nun dazu das beim Arbeiten immer wieder diese "Wartezeiten" entstehen. Das verhindert jedwedes vernünftiges Arbeiten, dazu brauche ich keine Glasfaser oder sonstwas. Dieser Sachverhalt ist bei Tests mit einem älteren Backup des Scripts übrigens der gleiche.


    Ein Ticket wurde von mir schon eingereicht und, wie von mir schon geahnt, alles bestens unsere Server laufen einwandfrei. Und ich solle meine Script gefälligst in Ordnung bringen und nur mit html-Dateien prüfen (was hat html mit php-scriptlaufzeiten zu tun?).

    Auf den von mir geschilderten Sachverhalt wird nicht eingegangen sondern dies wird scheinbar völlig ignoriert. Also null Hilfe, übrigens das erstemal bei einem eingereichten Ticket.

    Dafür haben wir vor kurzem erst auf Webspace 4000 mit SSD etc. gewechselt...


    Woran können diese Schwankungen in den Scriptlaufzeiten noch begründet sein? Vor allem vor dem Hintergrund das die Scripte in den letzten Monaten nicht geändert wurden und alles vorher (auf dem alten Webspace) und kurz nach dem Wechsel tadellos lief. Sicherlich, kommen immer wieder einmal solche "Wartezeiten" zustande, aber nicht so oft das es ein vernünftiges Arbeiten behindert.

    Die Laufzeiten wurden mittels eines kleinen PHP-Scripts ermittelt.


    ein ratloser

    Norbert

  • Was tut das Skript denn? Werden unterschiedliche Datenmengen verarbeitet oder tut es immer exakt das gleiche?

    Es handelt sich um das Backend eines Webshops. Dabei werden z.B. Alle Artikel einer Kategorie aus einer DB geholt und aufgelistet. Also keinerlei Berechnungen. Das gleiche bei Auflistung von Kategorien, beim Auflisten von Preistabellen... also eigentlich bei ALLEN Seiten die Das Backend zu bieten hat.

    Dabei wird, in einigen Seiten lediglich die Pagination bei einigen Tabellen neu 'berechnet'.

  • Basiert der Webshop auf einem Framework? Nur weil dein Script immer das selbe auf den selben Daten macht muss im Hintergrund nicht immer das selbe ablaufen. Da spielen oft Caches eine Rolle. Wenn z.B. der Symfony-Cache neu erstellt wird, dann kann das schon mal 10-Sekunden dauern und dann ist wieder für viele Stunden alles schnell. Auch andere Caches können da reinspielen. Aber natürlich auch die Auslastung bzw Überlastung des Webservers und/oder Datenbankservers. Da müsste man mal ein Profiling drüberlaufen lassen um zu sehen, was das Skript - oder die von ihm eingebundenen Framework-Funktionen in der Zeit so treiben und was genau da dann jeweils so lange dauert.

  • Basiert der Webshop auf einem Framework?


    Nein, es wird kein Framework verwendet. Einzig für die Seitenausgabe wird ein Cache verwendet.

    Ein Profiling machen? Kannst du mir hier Tipps geben?

    Aber (das berühmte aber...), vor Wechsel alles gut, nach Wechsel eben die massive Verschlechterung... Da kommt natürlich auch der Gedanke auf das entweder der Webserver und/oder der DB-Server "überlastet" ist. Wie kann ich dies am besten prüfen? Im Moment stelle ich ja nur die gesamte Scriptlaufzeit fest.

  • Naja, ein nicht Framework-basierter Shop ist schwer vorstellbar. Und wenn die Shopware nur ihr eigenes Framework mitbringt. Jedenfalls wird es vermutlich Code geben, der nicht von Dir oder Deinen Mitarbeitern geschrieben wurde.


    Für PHP Profiling gibt es relativ viel Software. Blackfire wäre z.B. eine davon. Da kann man genauer sehen, welcher Teil des Scripts wie lange braucht. Für den Webserver könnte man selbst ein paar möglichst einfache PHP-Skripte schreiben. Mit und ohne Datenbankzugriff, möglicht mit geloggter Zeitmessung der Durchläufe. Reines HTML mag zwar auch Hinweise auf allgemeine Überlastung des Webservers aufzeigen können, aber PHP ist halt zumindest näher an deiner realen Anwendung. Der Server mag HTML blitzschnell ausliefern können aber trotzdem bei PHP lahm sein. Mehr als 10 Sekunden grundloser Unterschied bei der Skriptausführung wäre allerdings so grottenschlecht, dass ich das keinem Hoster zutrauen möchte. Falls dann am Ende alles auf den Server hindeutet, hat man auch bessere Argumente beim Support. Wenn die das mit überschaubarem Aufwand selbst nachvollziehen können stehen die Chancen auf eine Überprüfung sicher besser.


    Welche PHP-Version verwendest Du? Eventuell solltest du auch die phpinfo() vom alten und neuen Server vergleichen um eventuelle relevante Unterschiede bei den verfügbaren Modulen und den Einstellungen herauszufinden. Die Datenbanken sind absolut identisch auf beiden Servern? Ein zusätzlicher Index auf der Kategorie-Spalte mag z.B. bei sehr vielen Produkten schon sehr viel bringen, wenn nach allen Produkten einer Kategorie abgefragt wird.


    Allerdings deutet es m.E. schon auf irgendeinen Cache hin, wenn die Zeit nicht immer so lang und zudem sehr unterschiedlich ist.

  • Danke für die Tipps. Werde diese mal ab-arbeiten und berichten.

    Nur wie geschrieben keinerlei Änderungen, weder am Script noch an den Datenbanken.

    Naja, mal sehen was ich da herausfinde...


    Bis demnächst

    Norbert

  • pasted-from-clipboard.png


    Hab bei mir (Wordpress Installation) auch solche Schwankungen feststellen können. Vor ca. 2 Wochen waren die DB Query's ziemlich hoch, diese sind aber wieder in Ordnung nach dem anschreiben vom Support und einem Beitrag hier im Forum. Hab gestern dann mal UptimeRobot auf meine Seite angesetzt. Dieser läd die Seite alle 5 Minuten (gecachte Version) und auch dort sieht man Ausschläge nach oben zu bestimmten Zeiten.


    Ich habe auch ein 4000er Webpaket wie du (Webhosting 4000 SE de a1)


    Kannst du mal im CCP gucken auf welchem Webserver du sitzt, eventuell sind wir ja beide auf dem gleichen (Ich: a2fa9)

  • Meine Besucher eher unwahrscheinlich, laut Cloudflare waren es die letzten 24 Stunden nur 200 Unique Visitors. Klar kann es sein das auf dem selber Server eine größere Deutsche Seite läuft die um 10 Uhr einen Ansturm erhält.


    Aber von 700ms Respone Time auf über 3 Sekunden. Ich weiß ja nicht wo der Server von UptimeRobot sitzt und wie ausgelastet dieser ist, wegen dem sind die Zeiten an sich ja nicht Aussagekräftig, aber es fällt auch beim Surfen auf der Seite auf das ab und an die Ladezeiten sehr schwanken.

  • Wenn du in die Logfiles vom uptime robot schaust, dann dürfte die Lokation öfters zwischen den Kontinenten wechseln. Das ist aber eigentlich egal, denn es geht da ja nicht um Performance sondern um Verfügbarkeit.

    "Security is like an onion - the more you dig in the more you want to cry"

  • So,

    mit uptimerobot habe ich nun verschiedene Seiten und Domains zwei Tage prüfen lassen und unglaubliche (hohe) Zugriffszeiten bekommen.

    Bei der Überprüfung der PHP-Einstellungen habe ich nun Unterschiede festgestellt nämlich das unterschiedliche PHP-Versionen eingestellt waren.

    Mehrere Domainnamen verweisen bei uns auf den besagten Webshop und bei einer Domain war diese aber anders als bei den anderen. Ich habe nun alle Einstellungen aller Domains exakt gleich vorgenommen.


    Nun besserten sich die Zugriffszeiten via uptimerobot ganz erheblich. Außer bei einer Domain die auf den Webshop verweist. Hier sind die Zugriffszeiten immer noch (teilweise) erheblich höher.

    Zusätzlich habe ich daraufhin die Logdateien der einzelnen Domains überprüft.


    Wir haben hier massive Abfragen vom mjbot (mj12bot.com) teilweise tausende, teilweise mit Urls die 7-8 Jahre alt sind. Nicht gleich häufig sind Abfragen vom ahrefsBot (ahrefs.com), ebenfalls mit URLs die teilweise über 7 Jahre alt sind. Damals lief noch eine Joomla-Installation hier.

    Immer wenn diese "Abfrageblöcke" bei uns aufschlagen schießen die Zeiten bei uptimerobot in die Höhe.


    Im Moment versuche ich, zumindest diese beiden zu sperren...

  • Wir haben hier massive Abfragen vom mjbot (mj12bot.com) teilweise tausende, teilweise mit Urls die 7-8 Jahre alt sind. Nicht gleich häufig sind Abfragen vom ahrefsBot (ahrefs.com), ebenfalls mit URLs die teilweise über 7 Jahre alt sind. Damals lief noch eine Joomla-Installation hier.

    Immer wenn diese "Abfrageblöcke" bei uns aufschlagen schießen die Zeiten bei uptimerobot in die Höhe.


    Im Moment versuche ich, zumindest diese beiden zu sperren...

    https://ahrefs.com/blog/robots-txt/


    https://mj12bot.com/


    http://www.botreports.com/m/mj12bot.shtml

  • Danke für die Links!

    Bestätigen meine Informationen. Und "versuche" bezieht sich darauf das ich die Einstellungen vorgenommen habe aber noch einmal 1-2 Tage warte und mir dann die Logdateien ansehe ob alle wie gewünscht funktioniert.


    Bis in Kürze...

  • @all

    So,

    ersteinmal Dank an alle für die Ideen und Hinweise.

    Ursächlich für meine Probleme scheine zwei Dinge gewesen zu sein:

    1. Fehlerhafte Servereinstellung für eine von 4 Domains
    2. Massenhafte Bots u.a. von Majestik

    Die Antwortzeiten haben sich mittlerweile wieder "normalisiert", bis auf Ausreisser die zu jeder beliebigen Tageszeit auftreten und Zeiten von bis zu 25 Sekunden erzeugen. Aber laut Uptimerobot geschieht dies max. 1-2 mal am Tag und nicht immer bei allen Domains. Halte ich also für normal da ja die Verbindungsgeschwindigkeit mit gemessen wird.


    Bis zum nächsten Problem... ;)