PHP Frage, Analyse Tool für Webseiten

[Domi83]

Hallo Leute, gibt es eine relativ simple Analyse mit der man prüfen kann wo es auf einer Seite harkt? Durch meine Recherchen bin ich auf blackfire.io gestoßen, dass dürfte aber für meinen Kollegen der die Seiten baut, etwas zu unübersichtlich sein.

Im Prinzip wäre auf relativ simple Art und Weise interessant, wo es gerade harkt. Wir haben eine Eingabemaske auf eine unserer Seiten, dort werden ganz am Ende Daten an einen anderen Server gesendet, überprüft und wir bekommen das "OK, ist eingegangen!" und fertig ist. Dieser Prozess dauert aus aktuell noch unerklärlichen Gründen länger als es vorher war.

Wenn die Damen des Hauses auf absenden gedrückt hatten, dauerte es maximal 1 - 2 Sekunden, dann kam die "Vielen Dank" Seite und fertig ist. Laut Aussagen der Damen, kann es auch schon mal bis zu 5 Sekunden dauern und bei dieser zeitlichen Abschätzung sind sie sich nicht mal 100% sicher.

Da wir einen weiteren Server für unsere Tests besitzen (kein Live-System) könnte ich dort im Apache auch Tools einbauen... nur wäre die Frage, mit was kann man da arbeiten was relativ simple und vielleicht auch kostenfrei ist, womit man mal sehen kann welcher Schritt ein paar Sekunden hängt?!

Gruß, Domi

 

[Crys]

Mehr habe für php noch nie gebaucht: php error_reporting
Man bekommt genau gesagt wo es hängt und wieso.

 

[Konto gelöscht]

Nimm den Firefox beispielsweise und drücke mal F12. Dann über den Reiter „Netzwerk“ kannst du sehen, worauf die Seite gerade wartet. Dann weißt du vielleicht schon, wo die Anfrage steht und warum. Über die anderen Reiter auch mal schauen, ob irgendwas nicht geladen werden kann

 

[Cool Master]

Dieser Prozess dauert aus aktuell noch unerklärlichen Gründen länger als es vorher war.

Ist es denn sicher, dass es ein Server Problem ist? Wenn ja was läuft alles auf dem Server? Evtl. läuft einfach zu viel für die vorhandenen Resourcen.

Wenn die Damen des Hauses auf absenden gedrückt hatten, dauerte es maximal 1 - 2 Sekunden, dann kam die "Vielen Dank" Seite und fertig ist. Laut Aussagen der Damen, kann es auch schon mal bis zu 5 Sekunden dauern und bei dieser zeitlichen Abschätzung sind sie sich nicht mal 100% sicher.

Das kann auch ein Internet Problem der Damen sein und muss nicht zwangsläufig am Server liegen. Routing Probleme beim ISP?

Ansonsten einfach mal mittels, wenn Linux, (h)top schauen was aktuell so an Resourcen verbraucht wird.

 

[Domi83]

Hallöchen... also es ist nicht nur bei uns so. Auch Kunden habe schon mal das Problem erwähnt, dass das Laden nach "Absenden" ein paar Sekunden länger dauert. Im Prinzip geht es um Versicherungen... Kollege hat im vergangenen Jahr eine Maske zusammen und die Daten werden (je nach Versicherung) in deren gewünschten Format übermittelt.

Der eine oder andere Versicherer prüft auch, ob die Daten innerhalb einer Zeit von X schon mal rein kamen und sagt dann auch "hallo, Doppelbuchung!", was ja bei nervösen Leuten mal passieren kann. Die Kehrseite ist, dass es welche gibt die das nicht prüfen und somit haben die Leute zwei Versicherungen abgeschlossen.

Als es noch in einem Zug durch rutschte, kam es nicht (bis ganz wenig) zu solchen Problemen. Via htop hatte ich schon mal die Auslastung geprüft, die Kiste schläft gefühlt (Quadcore und 16 GB Ram). Im Prinzip ist das ein simples hin und her...
1.) Versicherungsnehmer / Kunde gibt Daten ein
2.) Absenden -> Daten werden an die Versicherung gesendet
3.) Versicherung prüft (z.B. IBAN, Plausibilität der eingegebenen Daten etc.)
4.) Wenn OK, dann gibt es die Nummer des Versicherungsscheins (oder einen Fehler)
5.) Wenn die Nummer zurück kommt und alles ist OK, dann "Vielen Dank" Seite

Da wir mit mehreren Versicherungen zusammen arbeiten, kann man nicht mal sagen es liegt an der Versicherung XY... und wenn ich das von meinem Kollegen noch korrekt im Kopf habe, hat er via der Entwickleroberfläche (F12 im Browser) gesehen dass es ein paar Sekunden dauert. Aber dort steht nicht was PHP (Server-Seitig) macht.

Im errorlog steht auch nichts, denn es funktioniert ja... dauert halt nur ein paar Sekunden länger. Nun wäre halt die Frage welche Methode da "trödelt" und da hatte ich die Hoffnung, dass man das irgendwie herausfinden kann

 

[KeepXtreme]

Ganz dumme Frage: wie übermittelt ihr die Daten an die Versicherer? Skripte die Ihr über eine URL aufruft? Eventuell liegt die Verzögerung im Verbindungsaufbau (SSL/TLS-Verschlüsselung, DNS-Auflösung o.ä.) und gar nicht am Skript selber. Das kann dann auch mal ein Update gewesen sein, an das man eher nicht gedacht hat.

Was du machen könntest (Quick&Dirty) Skrip-Laufzeit an verschiedenen Punkten erfassen und am Skriptende in eine DB/Textdatei loggen...

 

[Domi83]

Kein Problem, ist ja keine dumme Frage... aber ja, wir haben von den Versicherern die URLs zu deren Servern bekommen. Bin jetzt kein Vollblut Programmierer, habe zwar auch ein wenig an den Schnittstellen herum experimentiert aber bei genaueren Beschreibungen könnte es dann harken.

Aber ja, der eine Versicherer hat eine SOAP Schnittstelle, der andere eine XML Schnittstelle, bei wieder einem anderen weiß ich dass da am Ende was von WSDL, ein weiterer braucht die Daten nur ganz simple als JSON String.

Es wird aber immer eine Verbindung via URL aufgebaut. Ich hab es zwar nicht erwähnt, dürfte aber in diesem Sektor verständlich sein, es sind auch immer SSL Verbindungen. Auch wenn es halt (wie du sagst) Quick & Dirty ist, wäre das wirklich ein Ansatz, die Laufzeit der Methoden mal zu messen und in eine Textdate oder in unsere MySQL Datenbank zu schreiben.

Als "IT Hausmeister" werde ich dann halt erst einmal zu rate gezogen, ob es Probleme an den Servern gibt und da habe ich aktuell halt keine feststellen können. Kollege ist auch gerade nicht im Haus, somit werde ich dann auch von den Mitarbeitern angesprochen und nun wollte ich mal schauen ob ich ihm da schon mal ein wenig unter die Arme greife kann um sagen zu können "schau dir mal Methode XY an, die Ausführung dauert am längsten"

 

[ayngush]

SOAP / XML / WSDL ist in diesem Kontext quasi alles das gleiche, nämlich eine SOAP-Schnittstelle. XML ist das Übertragungsformat, WSDL die Schnittstellendefinition und SOAP das Gesamtkunstwerk dahinter. Höchst wahrscheinlich wird da noch SAML über ISTS beim GDV für laufen (Authentifizierung und Autorisierung) - das laggt häufiger mal. Wir sind akkreditierter Bildungsdienstleister und Trusted Partner für "gut beraten" und nutzen diese Services zur Übermittlung und Abfrage der Bildungszeit. Das "laggt" auch immer mal, dann geht es ein paar Tage später wieder flott usw.

JSON deutet dann wieder auf eine REST-Schnittstelle hin. Das verursacht insgesamt viel weniger Overhead als SOAP mit SAML und dem ISTS vom GDV, das sollte deutlich schneller laufen.

Performanceprobleme können jedoch schon bei der DNS-Auflösung von der URL der Partnerschnittstellen anfangen und bei dem Partnersystem selbst enden.
Es gibt da so viele Stellen, an denen man ansetzten kann aber nur einige wenige, die mit der eigenen Infrastruktur zu tun haben.
Zum testen, ob DNS ein Problem ist, kann man mal kurzfristig ein paar betroffene Schnittstellen statisch in die hosts-Datei des entsprechenden Servers eintragen und Tests durchführen. Sollte das schon deutlich schneller laufen, muss man sich um ein besseres DNS-Caching für die Services bei euch kümmern. Bitte solche statischen Einträge für externe Dienste nur zu Testzwecken verwenden und nicht dauerhaft produktiv lassen, denn wenn die Partner mal die IP der Services ändern, sendet ihr das im Zweifelsfall an falsche Leute, im günstigsten Fall, bricht das einfach alles stumpf ab. Aber mit einen effektiveren Cache, ggf. mit längeren Laufzeiten, könnte man da schon was rausholen. Eventuell. Oder es liegt am Crypto. Unsere alten Webserver konnten das SAML-Crypto nicht so richtig schnell. Ein Upgrade auf modernere CPUs hat das ganze schon deutlich beschleunigt.

Ansonsten sind Laufzeitanalysen im PHP-Quelltext auch ganz passabel dafür. Einfach mal ein einfaches log mitschreiben lassen, bei der vor jedem relevanten Schritt ein Eintrag vorgenommen wird, dann kann man schon mal die "Übeltäter" etwas eingrenzen. Jedoch hat man damit keine Möglichkeit das Problem präzise auf "DNS" oder "CPU" oder so einzugrenzen, dafür muss man einfach "normale Performanceanalyse" betreiben, was ziemlich ätzend sein kann. (siehe oben)

 

[Domi83]

Alles klar, vielen Dank für die Aufklärung Mit meinem Kollegen habe ich eben mal via WhatsApp geschrieben und gehorcht was er sagt... Das blöde ist wohl, dass das sehr kurz vor seinem Urlaub aufgetaucht ist.

Da wir aber auch Test-Abschlüsse machen können, habe ich das eben mal ausprobiert und die "Netzwerkanalyse" im Firefox mitlaufen lassen. Beim zählen kam ich auf grob 10 Sekunden und der Browser sagt was von 8 Sekunden. Aber egal, beides auf jeden Fall viel zu lange.

Vielleicht kann ich aber für ihn schon mal etwas heraus finden... den Ablauf der Skripte kenne ich ja... vor ca. 5 Jahren hab ich die Basis dafür aufgebaut und er hat mein Grundkonzept für seine Maske übernommen und auf die Bedürfnisse angepasst. Vielleicht hat er da in den letzten Wochen etwas eingebaut was jetzt nicht ganz so gut war.

Ich würde aber definitiv wieder posten wenn ich ein Schritt weiter bin oder sogar eine Lösung habe

Gruß, Domi

 

[ayngush]

Ja... das Skript "form3.php" wird wohl im Hintergrund mit den Systemen der Versicherer kommunizieren und dabei kommt es zu diesen langen Warte- oder Haltezeiten. Das muss man jetzt halt mit den genannten Methoden aufdröseln. Im Zweifelsfall muss man sich ein eigenes Testszenario und Testsetup zusammen basteln. Hilft alles nichts, Performanceanalyse ist manchmal etwas umständlich.

 

[Domi83]

Hab vorhin in die Klasse eine Methode gebaut, die mir via append in eine Textdatei hinein schreibt. Hab das ganz simple gehalten... ich schreibe mir die Zeit hinein und die Methode (Anfang und Ende) hab dadurch schon auf den ersten Versuch heraus gefunden, welche Methode ca. 7 Sekunden zögert... morgen mal gucken was da alles drin steht

Die "Quick & Dirty" Lösung war also doch recht gut

 

[ayngush]

Anders geht es ja kaum. Serverseitig XDebug (bitte nicht auf Produktivsysteme, das frisst richtig Ressourcen....) mit VS Code hätte da eventuell auch geholfen aber manchmal muss man auch einfach mal pragmatisch an die Dinge herangehen.

 

[Sparta8]

Das sind sicher die Server der externen Versicherungsfirmen die mal länger mal kürzer für eine Antwort brauchen.

Für den User selbst kann man das schön über AJAX lösen. So auf die Art: Daten werden übertragen => Daten erfolgreich an Versicherung übertragen => Warten auf Antwort der Versicherung.
Dann wissen die Damen im Büro was genau passiert und können sich die Wartezeit besser erklären.

Den Submit Button nach dem Absenden deaktivieren, dann können die Nervösen auch nicht mehrfach auslösen.

 

[Domi83]

Moin... Das mit der AJAX Lösung hat mein Kollege auch schon in Betracht gezogen, will er auch so umsetzen wenn er wieder im Büro ist. Submit-Button hat er deaktiviert, hat allerdings einen kleinen Haken, den ich jetzt noch mal lösen muss... wenn man nun Submit drückt, wird er deaktiviert... aber wenn HTML5 sagt "hey, diese Checkbox ist required" darf der Button nicht deaktiviert werden.

Das war vermutlich seine "Quick & Dirty" Methode vor dem Urlaub mit dem deaktivieren von dem Button.

Aber kommen wir mal eben zu meinem Hauptproblem mit dem langen warten. Durch die von @KeepXtreme genannte Quick & Dirty Variante, habe ich das Problem eingrenzen und beheben können. Ja, die Abfrage / Prüfung der Daten gegenüber der Versicherung selbst dauert eine Sekunde... was ich allerdings nicht wusste, dass PHPmailer Skript welches Kollege bei uns eingebaut hat, greift auf Port 25 unseres Mail-Servers zu und ich habe vor ein paar Wochen am E-Mail Server (Postfix) hinterlegt, dass er Anfragen auf Port 25 für 5 Sekunden zurückhalten soll.

Hab nämlich aufgrund der SPAM Bekämpfung diverse Tutorials durch gewühlt, Foren durch geschaut wie andere Leute so vor gegangen sind und habe das eine oder andere übernommen. In diesem Fall war sogar ich selbst schuld, wieso die Ausführung so lange gedauert hat. Hätte mein Kollege den Submission Port verwendet, wäre dies nicht aufgefallen

Aber ich konnte damit das Problem finden und sogar lösen

 

[ayngush]

Sehr schön. Aber die Nummer mit Port 25 und so... keine Firewall / intrusion prevention / und Netzwerksegmente vor dem MTA am Start? Kann da jeder Server oder Client "einfach so" auf Port 25 zugreifen? Nicht gut...

Normalerweise kennen ich MailTransportAgents / Smarthosts so, dass davor eine firewall eingerichtet ist und dort und im MTA selber natürlich genau konfiguriert ist, wer ihn als MTA / als Relay von intern, von extern (als MX ggf.) usw. nutzen darf und alle anderen bekommen von der Firewall bei Anfragen auf Port 25 z.B. einfach mal trocken und stumpf die Pakete weggedroppt.
Kann man sich übrigens auch bis zu einer gewissen Größenordnung auch "einfach" gestalten, wenn man so etwas wie eine Sophos UTM oder ähnliches als Smarthost dafür verwendet.

 

[Domi83]

Kann da jeder Server oder Client "einfach so" auf Port 25 zugreifen? Nicht gut...

Klar, muss ja sogar...
a.) Steht der Server im Rechenzentrum
b.) Muss er ja auch E-Mails von anderen Servern annehmen können, sonst kann uns ja keiner eine E-Mail zukommen lassen.

Es geht hier also nicht um einen Server der bei uns im Büro steht Aber das ist ein anderes Thema.

Nachtrag1: Wenn es um das "einfach so" geht, nein... man muss sich schon mit Benutzer (E-Mail) + Kennwort anmelden... Ist also kein Open-Relay.

Nachtrag2: Hat nichts mehr mit dem Thema zu tun, aber E-Mails sind bei uns als Insel-System aufgebaut. Der Server von uns selbst im RZ (z.B. Hetzner) nimmt E-Mails an, unser Server hier im Büro holt sie ab und verteilt sie haus intern. E-Mails versenden geht auch wieder über den Server im RZ, aufgrund der statischen IP... Ja, man kann auch statische IPs für DSL Anschlüsse bekommen, macht aber zu oft Ärger (Berufserfahrung der letzten 15 Jahre bei uns und Kunden von mir).

 

[ayngush]

Klar, muss ja sogar...

Nein, muss nicht. Kann (sollte) man anders gestalten.

Bei uns ist das so (unser "Kram" steht aber auch bei uns im Serverraum im Haus):
Sämtliche relevanten Server / Services / Clients sind in jeweils eigenen Netzwerksegmenten (DMZ) mit doppelten Firewalls (inbound und outbound zum Segment). Zwischen den Segmenten (aktuell sind das 11 Stück, bin aber noch nicht fertig ) sind Firewallregeln eingerichtet, wer (Netzwerk / Clients / Gruppen) da was (Dienst + Protokoll) wohin (Zielnetzwerk / Zielsysteme) machen darf.
Alles, was da nicht konfiguriert ist, wird erst mal von der Firewall weggedroppt.
So geht auch prinzipiell erst mal kein (S)NTP, kein DNS kein SMTP Datenverkehr nach "draußen". Eigentlich geht gar kein Datenverkehr nach draußen, außer es gibt dafür eine Regeldefinition, einen Proxy oder einen konfigurierten Dienst.

Jeder kann aber von extern auf 25 auf unseren MX einliefern aber auf 25 auf dem MTA von internen Netzwerksegmenten zugreifen kann nur ein einziger Server (Exchange bei externen E-Mails) aus seinen eigenen Segment heraus.

Intern dürfen und können die Clients nur per MAPI auf den Exchange-Server zugreifen. Sämtlicher interner Datenverkehr auf Port 25, bis auf Exchange<->UTM, wird somit blockiert, weil dafür nichts konfiguriert ist.
Es kann ja nicht sein, dass ein User oder einer der Server sich mal was einfängt und dann eine ordentliche Datenschleuder entsteht. Das "externe Netzwerk" (wir haben extern ein kleines /29 Netzwerk) / die externen IPs bekommst du nicht so schnell von den Blacklists runter, wie sie draufgespammt werden...

Die Konfiguration, wer dann noch was als MSA-Relay nutzen darf ist dann nochmal eine ganz eigene. So darf der Webserver, der unsere Internetseite hostet (und bei unserer Werbeagentur mit Wartungsvertrag läuft) unseren extern erreichbaren MSA als Relay nach sicherer Anmeldung nutzen. Für die Kontaktformulare und irgendwelche Status-E-Mails, die sich die Agentur da eingerichtet hat. Das läuft aber nicht auf Port 25, sondern 587...

Probleme macht das übrigens nur, wenn man das "nicht richtig konfiguriert"; z.B: indem man keinen PTR-Eintrag für die Reverse DNS-Auflösung zum MTA vom provider konfigurieren lassen hat, oder IP-Adressen in "Endkunden-Netzwerksegmenten" bekommen hat, also kein für E-Mail-Server geeigneten Providervertrag / Internetanschluss verwendet.
Wir haben zum Beispiel eine Glasfaseranbindung an das Backbone von Telia Networks über Global Connect.
Davor hatten wir eine sauteure (500 EUR pro Monat) 2 Mbit/s SDSL-Leitung von Plusnet(ex QSC, ex Broadcom, ex KKFnet) ausschließlich für den E-Mail-Datenverkehr.
Man muss für Mail, wenn man damit nicht im RZ steht oder eine fertige Konfiguration eines Providers benutzt, eben eine dafür geeignete Internetanbindung und Konfiguration haben.
Hat man seine Mühle aber in einen RZ stehen, dann sollte man sich da dringend um die Standortvernetzung kümmern (VPN-Tunnel / WAN-Strecke etc.) damit man vom Büro aus nicht als "externer" am Server im RZ ankommt und man somit die Sicherheit nicht so richtig in den Griff bekommt, weil ja dann "alles" irgendwie für extern erreichbar gemacht werden muss.

 

[Domi83]

Kann (sollte) man anders gestalten.

Einigen wir uns auf "kann" und gut ist Ich habe grob angeschnitten wie es bei uns aussieht. Sicherheit ist gegeben, Probleme gibt es keine und das ich im MTA ein "postscreen_greet_wait" hinterlegt habe, war halt nicht sehr schlau durchdacht.

Es gibt zig Wege, Möglichkeiten und Varianten im IT Segment über die man sich da streiten könnte und jeder hat die "richtige" Lösung für sich gefunden. Es fängt mit den Clients an, geht zu den Servern, dazu kommt die Vernetzung, die Programmierung, die Software oder eingesetzte Hardware (z.B. Router, Switch) etc.

Aber dass würde des Topic sprengen.

Nachtrag: Manchmal könnten meine Aussagen falsch verstanden werden... sollte aber nicht böse gemeint sein Wollte nur sagen das es halt viele Wege gibt die nach Rom führen

 

[ayngush]

Joa... Wir setzen halt einfach Best Practises und etwas BSI Grundschutz um. Muss man ja auch schon allein wegen der DSGVO usw. aber ist ja auch Banane am Ende zählt, was gut und sicher ist.