Merkwürdiges Phänomen bei Serverantwort

Charlei

New Member
Hallo Community!

Ich habe hier eine ganz merkwürdige Sache.
Nicht aus Faulheit, sondern um möglichst wenig Verwirrung zu stiften reduziere ich die Thematik mal auf allgemein das nötigste, damit es nicht von anfang an zu breit diskutiert wird. Ich gehe dann aber gerne mit mehr Details auf euch ein.

Wir haben einen sehr gut ausgestatteten Rootserver der neusten Generation bei einem namhaften Provider. 256GB RAM, SSD, zig Kerne etc.
Also kein Shared Host oder schwacher V-Server oder so.

Mein Shopsystem ist grundsätzlich sicherlich nicht das aller schnellste und modernste, aber es funktiniert ansich spitze mit folgender Ausnahme:

Wir haben über 1 sek. reines Waiting innerhalb der TTFB. Lookup, initial connection, SSL alles vorher schon durch im millisekundenbereich. Also die Sekunde ist reines Warten, und die ist auch spürbar.

BEVOR jetzt hier alle aufschreien, dass es sicher am Script liegt und das 1000 Gründe haben kann (php, DB etc.) --> Das ist klar, aber darauf will ich gar nicht raus, sondern auf folgendes Phänomen:

Wenn ich den Shop mit allen identischen Inhalten, Plugins, Konfiguration etc. auf unsere Test-Sub-Domain kopiere und dort ausführe, dann ist das Waiting innerhalb der TTFB bei 2 sek., also doppelt so lang.

Es macht bei mir also einen Unterschied WO bei mir auf dem Server ein und die selbe Sache läuft.

Ich hätte jetzt keine Schmerzen, wenn trotz potentem Server bei wenig Last mein nicht-high-end Shop vielleicht dennoch 500ms Bedenkzeit braucht, aber 1 sek ist zu lang. Nach der ersten Auslieferungsverzögerung ist übrigens danach alles rattenschnell. Beim forschen wo das herkommen könnte bin ich eben dann drauf gekommen, dass es auf der test-sub schon doppelt so viel ist.
Eine Schlussfolgerung könnte sein:
Auf einer "gesundem" Serverumgebung bräuchte der Shop sagen wir mal realistisch 500ms zu verarbeiten. Bei mir durch irgendeinen unbekannten Umstand auf der Hauptdomain 1000ms und auf der Subdomain 2000ms.
Wenn es also diese Wundersame Problem in meiner Konstellation gibt, dann schaukelt es sich hoch.

Jemand Ideen?

Wär euch echt super dankbar für Unterstützung. Wir haben schon Tage und Nächte verbracht was herauszufinden und kommen nicht weiter. Hatten in all den Jahren wir das machen sowas auch noch nie zuvor.

Danke vorab für jede Idee und Input!

Da Mascht
 
Ich würde versuchen den entsprechenden Apache Prozess mit ltrace/strace auf den Zahn zu fühlen um zu sehen welche Aufrufe er macht und was diese an Zeit kosten...
 
Mal geschaut, was genau langsam vom Browser geladen wird? Im Firefox gibt bei "Extras" -> "Web-Entwickler" den "Inspektor". Da kann man schon mit schauen, was von der Seite langsam geladen wird. Manch mal kann es auch externer Content sein, welcher geladen wird und die gesamte Darstellung der Webseite verzögert.
 
Dinge, die ich (mit ähnlichen Auswirkungen) öfters beobachte:
  • Validierung des SSL-Zertifikates über einen langsamen bzw. nicht erreichbaren OCSP- oder CRL-Server
  • Nicht/schlecht erreichbare IPv6-Verbindung (trotz AAAA-Record) und Fallback auf IPv4
  • Einbindung externer Scripte (Ads, Analytics, Counter, Tracker) von schlecht erreichbaren Servern
 
Schonmal vielen Dank an alle für Eure Antworten und Ideen!

Da ich unterwegs nur mit dem Handy bin werde ich euch morgen aus dem Büro ausführlich antworten.

Nur schonmal vorweg, es geht nicht um zusätzliche externe Bestandteile, die irgendwas verzögern, sondern tatsächlich nur um die erste Antwort des Servers auf die Anfrage des Browsers mit der angeforderten Seite, sprich der erste Punkt im Waterfall. Und auch Lookup, SSL etc sind schon gelaufen und haben nichtmal einen Wimpernschlag gebraucht. Und dann kommt die „Bedenksekunde“.
Sobald die vorbei ist kommt die Seite rattenschnell daher samt sllen anderen Elementen im Waterfall.

Nachtrag:
Bin noch nicht im Büro, nur noch kurz die Info, dass statische Seiten nicht betroffen sind, sondern nur vom Shop generierte Seiten.
Wie gesagt, selbst wenn die Scripts nicht die flottesten sind, so müssten sie doch dennoch an jedem Ort des selben Server gleich lang brauchen, oder etwa nicht?
 
Last edited by a moderator:
Hier jetzt mal eine Veranschaulichung im Waterfall, Chrome dev-tools, network:

MOD: Bilder bitte immer als Anhang. Danke!

@Thomas Chr: danke prüfen wir...
@MrBrain: siehe meinen screenshot mit kommentaren
@Joe user: nein nein, schon überall - egal von wo aus
@whistler: danke prüfen wir...

Danke für weitere Unterstützung :-)
 

Attachments

  • screeshot-waterfall_serversupp.jpg
    screeshot-waterfall_serversupp.jpg
    209.3 KB · Views: 140
Last edited by a moderator:
Bleibt das Verhalten denn reproduzierbar, wenn man die Testdomain sehr oft aufgerufen hat? Denn das Produktivsystem dürfte von einem warmem Cache profitieren.

Ansonsten würde ich ein Profiling mit Tideways empfehlen, damit sind wir schon vielen Performancefressern auf die Schliche gekommen :)
 
https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/



Du solltest die Zahl der Ressourcen (CSS,JS,Fonts,Images) deutlich reduzieren und diese zudem minified ausliefern.

Kompression durch den Webserver durchführen lassen, statt durch die App.

Jedes nicht zwingend benötigte Paket/Modul/Plugin/Extension deinstallieren.

Jedes nicht zwingend benötigte Feature deaktivieren.

Grundsätzlich aktuelle Software verwenden, nicht veralteten Müll wie bei Debian und Co.

Sämtliche Konfigurationen optimieren und aktuell halten.

PHP-FPM statt mod_php und PHP 7.1 statt PHP 5.x/7.0 verwenden. Opcache aktivieren.

Apache MPM-Event + HTTP/2 + Brotli wirken sich enorm positiv aus.




Saubere, valide und aktuelle HTML5 + CSS3 + JS (ECMAScript 6 oder neuer) + SVG wirken oft Wunder.

Optimierte Bilder und Grafiken (kleinste mögliche Qualitätsstufe für JPEG, kleinerer Farbraum für PNG, JPEG für Fotos, PNG für Grafiken, GIF für Animationen, wenn möglich PNG durch SVG ersetzen).

Bei Webfonts auf Legacy-Formate wie EOT oder nicht unterstützte wie SVG verzichten, stattdessen optimierte WOFF2 und WOFF bevorzugen.




Es gibt noch viel mehr zu beachten und zu tun, aber das ist hier eher OT...
 
hi zusammen und nochmal danke für das ganze feedback!

alles davon ist klar, einleuchtend und richtig. es man kann 1000 sachen optimieren und ist noch lang nicht fertig.

wir gehen ja auch alles an, suchen zunächst aber mal das hauptproblem was zu enormer verzögerung beiträgt und wohl eben auch noch abhänging zu sein scheint, WO DAS SCRIPT LÄUFT.

wir sind dran und ich halte euch auf dem laufenden.
wer noch ideen hat bitte gerne, jedoch bitte bezüglich auf auslieferung der index OHNE alles was DANACH passiert, denn darum geht es aktuell nicht.

php konstellationen haben wir alle getestet, modul, cgi, fpm usw.
op cache ist am laufen.
forschen gerade noch rund um die DB...

alles andere haben wir schon auch noch auf dem zettel. wie gesagt versuchen mit prio vorzugehen.

lg
martin
 
Last edited by a moderator:
haben gerade herausgefunden, dass der spuk aufhört sobald man im backend des shops ist.

forschen da jetzt noch detaillierter und ich melde mich wieder.

und meint ihr, dass so ein faules ei zwischen produktiv und testumgebung alleine wegen "warmen caches" um das doppelte anschwellen kann?
 
alles andere haben wir schon auch noch auf dem zettel. wie gesagt versuchen mit prio vorzugehen.
Eure Prio ist falsch herum, solange alles Andere von mir genannte nicht passt, wird auch die TTFB nicht passen, denn Alles von mir genannte wirkt sich direkt auf die TTFB aus.

Und bezüglich der TTFB ist der Blog-Beitrag von Cloudflare absolut richtig und könnte fast zur Pflichtlektüre werden.
 
joe, da hast du recht. meine schlussfolgerung bezieht sich darauf, dass es nix mit netzwerk, php, server konfig, ssl usw. zu tun hat.

wir forschen bei den sql queries und sind schon fündig.

danach gehen wir dann gerne den sonstigen seitenaufbau an...

ich melde mich :-)

danke!
 
tut mir leid, dass ich mich so lange nicht zurück gemeldet habe, war verhindert.

haben gleich mehrere probleme behoben und einiges verbessert.

DB von maria DB auf mySQL umgestellt
Einige Queries optimiert, Indexe gesetzt
teilweise unsinnige und wiedersprüchliche Cache Control header entfernt
OP cache angeschmissen

auf live umgebung jetzt alles deutlich schneller.
auch auf der testumgebung GLEICH schnell - mit ausnahme der startseite. letztere ist auf der testumgebung immer noch über eine ganze sekunde langsamer. keine ahnung warum, aber kann damit leben so lange es live fluppt.

probleme mit der server konfig konnten wir nicht wirklich eruieren.


pläne jetzt:

umstieg auf http2,wobei das ja mit plesk nur mit nginx als proxy geht. mir wäre nur apche ansich lieber. hat einer einen tipp???

php auf 7 sobald ich noch ein älteres zusatz script los bin, was mich aktuell noch hindert.

wenn ich nochwas finde melde ich mich...

DANKE an alle :-)
 
Naja, ich denke die meisten Leute hier wollen genau wissen was auf ihren Systemen läuft. Und Plesk ist ja nicht unbedingt durchsichtig :-)
Vorallem kostet es auch dazu noch Geld.
Solange ich also kein Plesk brauch (weil Kunden auf meinem Server das wollen) würd ichs lieber nicht benutzen!

Unter deinem Link gibts doch ne ganz gute Beschreibung wie man nginx als Reverse Proxy unter Plesk einrichtet. Kannst ja mal (auf nem Testsystem?) ausprobieren!

Nginx als reverse Proxy ist für viele Anwendungsfälle heutzutage normal und sooo komplex ist das ganze auch nicht!
 
Back
Top