Server Support Forum


Zurück   Server Support Forum > >


Antwort
 
Themen-Optionen Thema bewerten
  #1  
Alt 14.02.2018, 16:26
Charlei Charlei ist offline
Registered User
 
Registriert seit: 02.2018
Beiträge: 6
Merkwürdiges Phänomen bei Serverantwort

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
Mit Zitat antworten

  #2  
Alt 14.02.2018, 16:57
ThomasChr ThomasChr ist offline
Registered User
 
Registriert seit: 08.2014
Beiträge: 362
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...
__________________
www.thomaschristlieb.de
Mit Zitat antworten
  #3  
Alt 14.02.2018, 18:10
Benutzerbild von mr_brain
mr_brain mr_brain ist offline
Registered User
 
Registriert seit: 08.2007
Beiträge: 1.504
mr_brain eine Nachricht über ICQ schicken mr_brain eine Nachricht über AIM schicken mr_brain eine Nachricht über MSN schicken mr_brain eine Nachricht über Yahoo! schicken
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.
__________________
goto; // Welcome 2 Inter.Net
Administration, Colocation, DDoS Mitigation, Nameserver & virtuelle Server
Produkte: www.welcome2inter.net/products
Mit Zitat antworten
  #4  
Alt 14.02.2018, 19:14
Benutzerbild von Joe User
Joe User Joe User ist offline
Registered User
 
Registriert seit: 11.2008
Ort: Hamburg
Alter: 39
Beiträge: 3.921
Ist die TTFB nur bei Deiner/Eurer externen Anbindung so hoch, oder ist sie unabhängig von der Client-Anbindung so hoch?

Dienste wie https://www.webpagetest.org/ können hier wertvolle Hilfe bieten.
__________________
PayPal.Me/JoeUserWings for LifeWings for Life World Run
RootForum CommunityFreeBSD Remote InstallationFreeBSD WebHosting System

„If there’s more than one possible outcome of a job or task, and one of those outcomes will result in disaster or an undesirable consequence, then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Mit Zitat antworten
  #5  
Alt 14.02.2018, 19:33
Whistler Whistler ist offline
Support Guru
 
Registriert seit: 10.2008
Beiträge: 2.649
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
Mit Zitat antworten
  #6  
Alt 14.02.2018, 21:33
Charlei Charlei ist offline
Registered User
 
Registriert seit: 02.2018
Beiträge: 6
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?

Geändert von Charlei (15.02.2018 um 07:39 Uhr)
Mit Zitat antworten
  #7  
Alt 15.02.2018, 09:23
Charlei Charlei ist offline
Registered User
 
Registriert seit: 02.2018
Beiträge: 6
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 :-)
Miniaturansicht angehängter Grafiken
-screeshot-waterfall_serversupp.jpg  

Geändert von Thorsten (15.02.2018 um 17:14 Uhr)
Mit Zitat antworten
  #8  
Alt 15.02.2018, 11:21
PHP-Friends PHP-Friends ist gerade online
verifizierter Anbieter
 
Registriert seit: 08.2014
Ort: Oberhausen
Beiträge: 609
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
__________________
PHP-Friends | vollvirtualisierte SSD-Server
PHP-Friends GmbH | Ruhrorter Str. 55a | 46049 Oberhausen
Geschäftsführer Marvin Strauch, Tim Schneider
USt-IdNr. DE 301 459 640
Handelsregister Amtsgericht Duisburg, HRB 28335
E-Mail hi@php-friends.de | Telefon +49 201 857 938 01 | Fax +49 201 857 938 00
Mit Zitat antworten
  #9  
Alt 15.02.2018, 11:42
Benutzerbild von Joe User
Joe User Joe User ist offline
Registered User
 
Registriert seit: 11.2008
Ort: Hamburg
Alter: 39
Beiträge: 3.921
https://blog.cloudflare.com/ttfb-tim...ed-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...
__________________
PayPal.Me/JoeUserWings for LifeWings for Life World Run
RootForum CommunityFreeBSD Remote InstallationFreeBSD WebHosting System

„If there’s more than one possible outcome of a job or task, and one of those outcomes will result in disaster or an undesirable consequence, then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Mit Zitat antworten
  #10  
Alt 15.02.2018, 11:52
Charlei Charlei ist offline
Registered User
 
Registriert seit: 02.2018
Beiträge: 6
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

Geändert von Charlei (15.02.2018 um 11:55 Uhr)
Mit Zitat antworten
  #11  
Alt 15.02.2018, 12:14
Benutzerbild von mr_brain
mr_brain mr_brain ist offline
Registered User
 
Registriert seit: 08.2007
Beiträge: 1.504
mr_brain eine Nachricht über ICQ schicken mr_brain eine Nachricht über AIM schicken mr_brain eine Nachricht über MSN schicken mr_brain eine Nachricht über Yahoo! schicken
Zitat:
Zitat von Charlei Beitrag anzeigen
... forschen gerade noch rund um die DB...
Wie wird auf die DB zugegriffen? Versucht vielleicht die DB immer den Domain-Teil @localhost etc. beim Benutzernamen aufzulösen.
__________________
goto; // Welcome 2 Inter.Net
Administration, Colocation, DDoS Mitigation, Nameserver & virtuelle Server
Produkte: www.welcome2inter.net/products
Mit Zitat antworten
  #12  
Alt 15.02.2018, 12:34
Charlei Charlei ist offline
Registered User
 
Registriert seit: 02.2018
Beiträge: 6
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?
Mit Zitat antworten
  #13  
Alt 15.02.2018, 12:41
Benutzerbild von Joe User
Joe User Joe User ist offline
Registered User
 
Registriert seit: 11.2008
Ort: Hamburg
Alter: 39
Beiträge: 3.921
Zitat:
Zitat von Charlei Beitrag anzeigen
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.
__________________
PayPal.Me/JoeUserWings for LifeWings for Life World Run
RootForum CommunityFreeBSD Remote InstallationFreeBSD WebHosting System

„If there’s more than one possible outcome of a job or task, and one of those outcomes will result in disaster or an undesirable consequence, then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Mit Zitat antworten
  #14  
Alt 15.02.2018, 12:43
Benutzerbild von Joe User
Joe User Joe User ist offline
Registered User
 
Registriert seit: 11.2008
Ort: Hamburg
Alter: 39
Beiträge: 3.921
Zitat:
Zitat von Charlei Beitrag anzeigen
haben gerade herausgefunden, dass der spuk aufhört sobald man im backend des shops ist.
Das Backend ist garantiert auch erheblich schlanker als das Frontend.
__________________
PayPal.Me/JoeUserWings for LifeWings for Life World Run
RootForum CommunityFreeBSD Remote InstallationFreeBSD WebHosting System

„If there’s more than one possible outcome of a job or task, and one of those outcomes will result in disaster or an undesirable consequence, then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Mit Zitat antworten
  #15  
Alt 15.02.2018, 13:05
Charlei Charlei ist offline
Registered User
 
Registriert seit: 02.2018
Beiträge: 6
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!
Mit Zitat antworten
Antwort

Lesezeichen


Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist aus.
HTML-Code ist aus.

Gehe zu

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Merkwürdiges Verhalten - Verzögerungen durch Apache SirCarmine Webserver 0 03.07.2014 13:02
merkwürdiges Problem, Website verlangt Passwort coder44 Virtuelle Server 2 27.08.2013 23:47
Merkwürdiges Problem mit Dovecot/POP3 Login laptop24 Mail 0 09.06.2011 00:30
Komisches Phänomen ostrohschein Dedizierte Server 3 04.06.2007 23:03





Powered by vBulletin® Version 3.8.11 (Deutsch)
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2018 DragonByte Technologies Ltd.