nicht angemeldet
Karl Heinz
TS
Karl Heinz
TS
Karl Heinz
TS
Karl Heinz
Hallo,
hinsichtlich des Online-Shop www.krusche-outdoor.de haben wir ziemlich mit der Ladezeit der Seiten zu kämpfen.
Dummerweise tritt das langsame Laden der Seiten nicht immer auf sondern nur temporär. Das erschwert das Identifizieren der Ursache ungemein.
Besonders häufig treten die langsamen Ladeseiten dann auf, wenn man etwas in den Warenkorb legt oder im Checkout Prozess. Man wartet hier teilweise mehrere Sekunden (manchmal sogar über 10 Sekunden) bis eine Seite geladen ist.
Könnt Ihr mir sagen was das beste Vorgehen ist um die PRIMÄRE Ursache für die extrem langsamen Ladezeiten (die dummerweise nicht immer sondern nur temporär auftreten) zu finden?
Hinsichtlich der Server-Hardware ist die Ausstattung mit einem eigenen Server sehr gut. Die Hardware ist deshalb vermutlich nicht die Ursache.
Viele Grüße
Hello,
welches OS für den Webserver?
Wenn es ein Linux ist, empfehle ich mal lsof.
Es könnte sich um einen Dead-Lock handeln.
Liebe Grüße
Tom S.
Hallo TS,
welches OS für den Webserver?
Laut Hoster wird ein angepasstes Linux Debian genutzt.
Wenn es ein Linux ist, empfehle ich mal
lsof.
Ich habe mir mal diesen Artikel durchgelesen:
https://wiki.ubuntuusers.de/lsof/
Ich persönlich habe keinen direkten Zugriff auf das Debian System möchte die Programmierer aber gerne bei der Lösungsfindung unterstützen. Aus diesem Grund die Frage, welche Erkenntnis du Dir konkret von der lsof Ausgabe erhoffst. Wie kommst du zu der Vermutung, dass geöffnete Dateien die Ursache für den langsamen Server sein könnten bzw. welche lsof Ausgabe würde Deine Vermutung bestätigen?
Es könnte sich um einen Dead-Lock handeln.
Was wäre denn die einfachste Möglichkeit um herauszufinden, ob solch ein Dead-Lock tatsälich die Ursache ist?
Hello,
fang mal mit dem Frontend an. F12 und Netzwerkanalyse. Dort solltest Du sehen, welche Requests länger brauchen, als andere.
Um die weiterreichenden Fragen zu klären, müsste man eine Menge über euren Seiten-/Frameworkaufbau wissen. Werden alle Zugriffe über eine zentrale Ressource (index.php) geroutet, oder finden parallele Zugriffe, z. B. per AJAX statt (nachladen von Inhalten)?
Werden ggf. CSS-Dateien oder JS-Dateien "on-the-fly" zusammengestellt?
Und die mögliche Datenbankbremse wurde ja auch schon erwähnt.
Gerne bremsen auch AJAX-Requests, wenn sie mit der Sessiondatei arbeiten. Da muss dann der eine erst fertig sein, bis der nächste zugreifen darf.
Liebe Grüße
Tom S.
Und die mögliche Datenbankbremse wurde ja auch schon erwähnt.
Was wäre denn das richtige Vorgehen um zu überprüfen, ob die Datenbank als Ursache in Frage kommt?
Hello,
ich bin jetzt wieder zuhause und habe das eben auf dem Desktop aufgerufen nach Leerung des Cache. Auf dem Tablet konnte ich das ja leider nicht testen. Und auf den Rechnern im Seminarraum beim Kunden habe ich immer einen Proxy dazwischen, sonst komme ich gear nicnt raus.
Mit transparentem Internetzugriff wurden 49 Ressourcen aufgerufen und die Befriedigung der Requests hat 19,42 Sekunden gedauert. Das ist heftig angesichts meiner gut funktionierenden DSL-Leitung mit tatsächlichen 25Mbit/5Mbit Kapazität.
Ich bin mir sicher, dass Eure Seite überarbeitet werden muss.
Ich habe hier jetzt noch einen Drängler (einsiedler) auf dem Zettel, dem ich versprochen hatte zu helfen :-O
Aber das kann ich nur am heimischen PC...
Eine wirksame Analyse wäre eien echte Aufgabe. Man müsste sich durch euer gesamtes System erst einmal aufmerksam hindurchkauen, bis hinten gut Verdautes herauskäme :-)
Liebe Grüße
Tom S.
Eine wirksame Analyse wäre eien echte Aufgabe. Man müsste sich durch euer gesamtes System erst einmal aufmerksam hindurchkauen, bis hinten gut Verdautes herauskäme :-)
Könntest du Dir vorstellen die Aufgabe zu übernehmen, ich kenne Dich ja :-), wenn du das machst würde es richtig gemacht, müsste dann natürlich erstmal mit meimem Kunden sprechen.
Könnt Ihr mir sagen was das beste Vorgehen ist um die PRIMÄRE Ursache für die extrem langsamen Ladezeiten (die dummerweise nicht immer sondern nur temporär auftreten) zu finden?
Profiling ;-) Konkretere Tipps sind bei der Beschreibung schwierig. Das temporäre Auftreten könnte auf eine Ursache in der Datenbank hindeuten: wenn der Query-Cache antwortet, ist es schnell, wenn die DB aber z.B. erst einen großen Filesort machen muss, ist es langsam. Mysql bietet hier zur Sichtung das slow-query-log an.
Das temporäre Auftreten könnte auf eine Ursache in der Datenbank hindeuten.
Aus welchem Grund deutet temporäres Auftreten auf eine Ursache in der Datenbank hin? Die Datenbank kann doch genausogut permanent langsam sein, warum sollte diese nur temporär langsam sein?
Das temporäre Auftreten könnte auf eine Ursache in der Datenbank hindeuten.
Aus welchem Grund deutet temporäres Auftreten auf eine Ursache in der Datenbank hin? Die Datenbank kann doch genausogut permanent langsam sein, warum sollte diese nur temporär langsam sein?
Ich schrieb, dass es darauf hindeuten könnte! Die Antwort auf Deine Frage steht in dem Rest meiner Antwort, die Du aus dem Zitat rausgelassen hast:
"... wenn der Query-Cache antwortet, ist es schnell, wenn die DB aber z.B. erst einen großen Filesort machen muss, ist es langsam. Mysql bietet hier zur Sichtung das slow-query-log an."
Besonders häufig treten die langsamen Ladeseiten dann auf, wenn man etwas in den Warenkorb legt oder im Checkout Prozess. Man wartet hier teilweise mehrere Sekunden (manchmal sogar über 10 Sekunden) bis eine Seite geladen ist.
Selbst die Startseite und Übersichsseiten weisen teils sehr grenzwertige Zeiten auf: 3-8 Sekunden konnte ich messen, ohne nachgeladene Inhalte, nur für die initiale Serverresponse. Der Quelltext weißt ein Oxid aus, davon habe ich keine Ahnung, kann mir aber nicht vorstellen, dass das normal sein soll. Wenn der Load auf dem Server gleichzeitig niedrig sein sollte, wiederhole ich meinen Tipp, mal die Datenbank zu checken. Oder aber das Oxid hat irgendwelche Plugins, die Unsinn machen.... Aber wie gesagt: Du musst messen. Da sich die Perfomanceengpässe aber recht leicht provozieren lassen, sollte das schnell auffindbar sein....
Selbst die Startseite und Übersichsseiten weisen teils sehr grenzwertige Zeiten auf: 3-8 Sekunden konnte ich messen, ohne nachgeladene Inhalte, nur für die initiale Serverresponse.
Womit hast du die Zeiten gemessen? Mit F12 und Netzwerkanalyse oder über einen anderen Weg?
Womit hast du die Zeiten gemessen? Mit F12 und Netzwerkanalyse oder über einen anderen Weg?
Nee, ich habe den Server gehackt und dort gemessen! ;-) Nee: Netzwerkanalyse.
Hallo,
welchen Wert (in Sekunden) würdet Ihr für die maximale Seitenladezeit anstreben bzw. empfehlen?
Hier mal ein paar Google Analytics-Daten, die bei der Eingrenzung der Ursache (das langsame Laden der Seiten) helfen sollten:
welchen Wert (in Sekunden) würdet Ihr für die maximale Seitenladezeit anstreben bzw. empfehlen?
Schneller = besser. Immer. Ich kann nicht beurteilen, was Oxid da wie macht. Womöglich wirst Du die optimalen Zeiten nur mit einem eigenen (Proxy-)Cache erreichen können. Vielleicht wendest Du dich da besser an Oxid-Profis und/oder ein Support-Forum von denen.
Ich würde mich an Deiner Stelle zunächst um die üblen Flaschenhälse kümmern, wenn z.B. eine Produktübersicht 6 Sekunden für die initiale Serverresponse braucht (Zeit zwischen Browseranfrage und vom Server gelieferten Markup. Ohne Bilder, JavaScript usw!). Selbst wenn Oxid lahm sein sollte, mehr als 2 Sekunden kann ich mir eigentlich nicht vorstellen.
Um alle Deine Frage in Gänze zu beantworten, würde es m.E. auf Consulting hinauslaufen ;-) Das Internet bietet Dir zu den ganzen Begriffen aber schon eine Menge Input.
Dummerweise tritt das langsame Laden der Seiten nicht immer auf sondern nur temporär. Das erschwert das Identifizieren der Ursache ungemein.
Wenn du den Fehler noch nicht reproduzieren kannst, ist ein aktives Profiling nur schwer möglich. Stattdessen kannst du mit passivem Profiling wichtige Metriken für alle (oder alle x-ten) Anfragen aufzeichnen. Das geht bspw. mit https://blackfire.io. Damit erhälst du fast alle Metriken, die dir auch xdebug aufzeichnen würde und diverse interaktive Diagramme, um schlau aus den Daten zu werden.
Wenn du den Fehler reproduzieren kannst, dann kannst du dir die Kosten für blackfire sparen und mit xdebug Profiling-Daten aufzeichnen. Visualisieren lassen kannst du sie dir mit KCacheGrind (für Linux) oder QCacheGrind (für Windows).
Die Werkzeuge sind einigermaßen kompliziert einzurichten und auch zu bedienen, aber so gigantische Engpässe, die momentan bei auch auftreten, geben sich in aller Regel auf den ersten Blick zu erkennen.
Besonders häufig treten die langsamen Ladeseiten dann auf, wenn man etwas in den Warenkorb legt
Das Ändern der Stückzahl im Warenkorb dauert (mit dem Neuladen) verifizierbar 10 Sekunden, der Abruf des Warenkorbs allein 3.
An der Stelle musst Du halt durchhecheln und durchmessen, was da alles gemacht wird. Also Datenbankzugriffe, Zugriffe auf das Dateisystem, Zugriffe auf externe Ressourcen (Lagermanagement?) e.t.c. p.p.
An der Stelle musst Du halt durchhecheln und durchmessen,
define ('DEBUG', true ); # false zum Abschalten
# …
if ( DEBUG ) {
$debugName = "DER VON DIR VERGEBENE EINDEUTIGE NAME für die Aktion";
$debugStartTime[$debugName] = microtime( true );
}
### Hier Deine Aktionen (Befehlszeilen) ###
if ( DEBUG ) {
error_log("DEBUG: Aktion " . $debugName . " dauerte " . microtime( true ) - $debugStartTime[$debugName] . " Sekunden.");
}
Mit
grep "DEBUG:" /var/log/apache2/error.log
findest Du im Error-Log alle Ausgaben für alle Messungen.
Mit
grep "DER VON DIR VERGEBENE EINDEUTIGE NAME für die Aktion" /var/log/apache2/error.log
kannst Du dann nachsehen wie lange bestimmte Aktionen gedauert haben. Bei Auffälligkeiten musst Du dann tiefer einsteigen und herausfinden warum das so ist. Wie gesagt ist das für Dateisystemzugriffe, Datenbankzugriffe und alle Zugriffe auf externe Ressourcen zu machen. Was dann genau zu tun ist kann man nur im Einzelfall entscheiden und darstellen. Ein "Kochbuch" zu dem Thema mit Abdeckung von nur 5% der wahrscheinlichsten Fälle würde ich mir gut bezahlen lassen…
Update: an verschachtelte Messungen angepasst.