Äh... offenbar nicht, wenn es doch eine Lösung gibt? @Dominik Späte kanntst du damit nochmal konkreter werden, für welche Situationen sich dieser Vorschlag aus deiner Sicht anbietet und auch umsetzen ließe?
Es wird von einer Lösung gesprochen ohne auf das Problem zu zeigen. Hier hat noch niemand Stellen genannt, die genau das von Dominik angesprochene Optimierungspotenzial haben. Genannt wurde die dynamic_theme_style.css.php, die das Problem gar nicht aufweist.
Keiner hat auf das Problem gezeigt? Ja ok, fangen wir von mir aus gerne wieder bei 0 an: Hallo Moritz, ich habe mehrfach am Tag übermäßig lange Server Response Zeiten, z.B. 36 oder sogar 100 Sekunden. Der Hoster sagt, das liegt an einer PHP-FPM-Slot-Begrenzung, die nicht sonderlich kleinlich eingestellt ist und sich von Tarif zu Tarif sich nicht unterscheidet. Ich habe den besten und teuersten Shared Hosting Tarif von All-Inkl.com. Was kann ich tun? Danke!
Konnte es mit Safari nun erneut reproduzieren und das hier steht in den Safari Entwicklertools. Ich versteh es einfach nicht.... Seite komplett zerschossen, nur Text untereinander - kein Layout. Nach einem Reload alles wunderbar....aber warum nur? Failed to load resource: Der Vorgang konnte nicht abgeschlossen werden. (kCFErrorDomainCFNetwork-Fehler 303.)
@L & B Kurze Frage damit ich das ausschliessen kann: Habt ihr in eurem Shop auch Module von Xycons installiert und am laufen?
Naja, wenn man keinen schreibenden Zugriff mehr braucht. Lesend stehen die Session-Variablen nach session_write_close() schon noch zur Verfügung. Zumindest nicht direkt. Aber die während der Ausführung blockierten Skripte leisten sicher einen Beitrag dazu, dass das Limit an PHP-Prozessen erreicht wird. Und bei @DrGuu haben wir das Problem direkt. Wäre doch cool, wenn es eine gemeinsame Lösung gäbe Das stimmt. Aber gab's nicht z.B. mit der request_port.php ein Problem? Mein Verdacht geht ohnehin eher in Richtung aggressiver Bots, die das Session-Cookie händeln können und alle 100ms einen Request absetzen oder so. Aber auch, wenn ich im Admin die Bestellübersicht aufrufe, habe ich gleich zack 7 XHR-Requests. Stimmt. Dass dennoch etwas in der $_SESSION-Variable steht, hatte mich zu der Annahme veranlasst. War aber mal anders, oder? Wenn die main.min.css älter als 24h war oder so? Da war jetzt nicht alles wichtig. Deshalb nochmal die Kernidee: Session-Datei in einer möglichst frühen Phase der Skriptausführung freigeben, um parallele Requests schneller abfertigen zu können.
Spontane Google Suche dazu: Vom Aussehen erinnert mich der Fehler an damals den "Unschönen Seitenaufbau" - das war ja ein Problem mit Google und dem Template... (Link nur für registrierte Nutzer sichtbar.) Nur das es halt wenigstens dann ohne Hand an zu legen noch nachgeladen hat, es sah nur auf den ersten Blick unschön aus. Nun bleibt es so bis der User manuell die Seite neuladet....
Natürlich meinte ich es so, du hast es jetzt besser ausgedrückt . In der Theorie korrekt. Mir fehlt hier der Beweis, dass der Shop tatsächlich so viele blockierende Requests hat. Die Anzahl in Frage kommender Requests hat sich jetzt in den letzten Jahren nicht großartig verändert und hier wird ein wenig so diskutiert, als gäbe es ein neues, großes Serverressourcenproblem. Das erkenne ich noch nicht. "Das Problem" ist eben weiterhin nicht so genau eingekreist, dass klar wäre, was die Lösung ist. Hier gibt es bisher nur vage Vermutungen ohne Substanz. Weniger Session-Locking ist eine tolle Forderung, bringt uns aber nicht weiter, wenn nicht klar darauf gezeigt wird, wo es denn fäschlicherweise und vor allem in problematischem Umfang passiert. Bei Requests an die request_port.php tritt Session-Locking auf. Ich sehe nicht, dass so viele gleichzeitige Requests an die request_port.php gesendet werden, als dass das ein ernsthaftes Problem wäre. Mag sein, dass es da mal so einen Mechanismus gegeben hat. Aber ein Request pro 24h ist ja völlig irrelevant. Das ist auch Devise bei unserer Entwicklung. Jetzt den alten Code nach Stellen zu untersuchen, wo man ein paar Millisekunden sparen kann, indem ein session_write_close() früher passiert, sieht mir mehr nach einer Mikrooptimierung aus als der Lösung eines angeblich großen Problems.
Deinen Fall habe ich schon verstanden und ich möchte auch gerne helfen. Mit auf Problem zeigen meine ich, dass noch keiner die tatsächliche Ursache erkannt hat, wir also immer noch auf Ursachenforschung sind. Es wurde hier ein wenig so diskutiert, als wäre die Ursache bereits benannt und wir müssten nur noch die entsprechende Umprogrammierung durchführen. Es ist schon richtig, dass es wahrscheinlich etwas mit Session-Locking zu tun hat, aber welches PHP-Script die Session über 30 Sekunden offen hält, ist bisher unbekannt. Mir fällt bisher nichts ein, das im laufenden Shopbetrieb durch einen Besucher so viel Zeit in Anspruch nimmt.
Eventuell ein Problem mit deimem MAC und Safari guckmal hier https://macreports.com/safari-kcferrordomaincfnetwork-error-blank-page-fix/
Also zeitlich dazu passend könnten folgende Einträge sein: Aus den Apache Logs: Aus den Gambio Shop Logs: - Siehe Bild im Anhang - Hatte ich auch schon gesehen aber es kommt an mehreren Macs vor und eigentlich kannte ich das Problem davor nur von Windows 10 PC mit Firefox. Das es auch auf dem Mac auftritt hat mich total überrascht. Es ist aber leider nicht nur auf meinen speziellen Mac beschränkt.
Noch ein Fehler aus dem Safari Error Log als der Fehler auftrat: Code: Refused to execute https://googleads.g.doubleclick.net/pagead/viewthroughconversion/847197XXX/?random=1619713659XXX&cv=9&fst=1619713659XXX&num=1&bg=ffffff&guid=ON&resp=GooglemKTybQhCsO&eid=2505059XXX&u_h=900&u_w=1440&u_ah=800&u_aw=1440&u_cd=24&u_his=2&u_tz=120&u_java=false&u_nplug=1&u_nmime=3>m=2oa4l3&sendb=1&ig=0&data=event=gtag.config&frm=0&url=https://www.XXXXX-XXXX.ch/de/&tiba=Startseite | XXXX-XXXXX.ch - XXXr Online-Shop&dg=e&hn=www.google.com&async=1&rfmt=3&fmt=4 as script because "X-Content-Type-Options: nosniff" was given and its Content-Type is not a script MIME type. Mit Safari bekomme ich den Fehler wirklich sehr oft reproduziert. Immer beim ersten Seitenaufruf nachdem alle Website Daten gelöscht wurden.
Nein, nichts von Xycons. Vielleicht auch einfach ein schleichender Prozess, der zum Teil durch mehr Traffic und zum Teil durch Refactoring und zu einem Teil schon immer bestand? Joa. Mach doch mit und schau dir mal für ne Woche an, ob du auch solche Aussetzer hast und setz mal auf einem externen Server das Reponse Time Mess-Tool auf, mit einem Cronjob auf Intervall 1 Minute: (Link nur für registrierte Nutzer sichtbar.) Im Slow PHP Log stehen ja die Sachen, die lange dauern - da ist zwar keine Zeit mit angegeben, aber wenn du möchtest, frage ich da nochmal nach der Zeitschwelle, ab der es einen Eintrag im Log gibt. Nach meinem (zugegebenermaßen Laien-)Verständnis braucht es keine PHP-Scripte die 30 Sekunden laufen, oder habe ich das falsch? Ich dachte so: Ein Script braucht mal länger (Server-Schwankung oder langwierigere Aufgabe), dann kommt noch sowas dazu, und dann ist das erste Ding mit offener Session pausiert in der Queue. Dann kommen 10 weitere Aufrufe, die sich hinten anstellen müssen, und die Warteschlange wird immer länger. Wenn man Glück hat, löst es sich nach 4-8 Sekunden auf, sonst mal erst nach 30 oder nach 100 Sekunden. Also dass es DIE EINE PHP-Datei oder DEN EINEN Prozess der 30 Sekunden dauert gar nicht gibt, sondern nur gleichzeitige Zugriffe mit der selben Session, die in Summe 30 Sekunden Ladezeit brauchen. Reicht doch nach Dominiks Theorie, oder? Und wenn dann jeder Ajax Request dazuzählt.. Auf die Anzeige von Preisen nach Auswahl einer Varkombi warten wir auch gelegentlich mal etwas länger - oder er kommt gar nicht. Ok. Hörte sich zwischendurch für mich so an wie: "Problem? Welches Problem?" Weil Server-technisch wäre für uns der nächste Schritt ein managed Server, und dass der für einen Shop unserer Größe und mit unseren Zugriffszahlen nötig ist, kann ich mir nicht so recht vorstellen. Kann ich denn noch was helfen, um das Problem einzukreisen? Noch andere Logs, Screenshots, Fragen an den Hoster weitergeben o.ä.?
Ich habe mal aufs Template umgeschaltet aber der exakt gleiche Fehler tritt auch dort auf. Es macht keinen Unterschied ob Theme oder Template. Ebenso habe ich Google Analytics mal ausgeschaltet. Das hat jedoch auch nichts gebracht.
Den Beweis wird es kaum geben. Hinter ein paar Punkte hatte ich dank Deiner Ausführungen dann auch stillschweigend Häkchen gemacht. Deshalb mal explizit: Prima, dass Ihr das Session-Blockade-Problem auf dem Schirm habt und Session schon einspart, wo es geht! Ja, ich kann mir auch nicht vorstellen, dass die paar wenigen XHRs im Frontend den Shop lahmlegen. Deshalb an der Stelle: Vielen Dank für Deine Zeit und Erläuterungen! Mit "Problem" bezog ich mich auf die Überschrift des Themas. Die "vage[n] Vermutungen ohne Substanz" sind für mich aber durchaus "Indizien", wenn @L & B von "täglich mehrfach" Log-Einträgen bzgl. "session_start()" schreibt. @L & B Weißt Du, was all-inkl da als Limit festgelegt hat? Nochmal: Das "Problem" ist sicher nicht die blockierte Session-Datei. Das Problem ist, dass es bei @DrGuu und @L & B zu unerwünschten Beeinträchtigungen kommt. Das sehe ich durchaus als "großes Problem". Die frühzeitige Freigabe der Session-Datei betrachte ich natürlich nicht als die ultimative und einzige Stellschraube, aber als durchaus größeres Puzzle-Teil der Lösung.
Eine Sache versteh ich nicht: Ich habe auf unserem Server auch noch einen Testshop - eine Neuinstallation von 4.2.1 also wie der Live Shop jedoch unberührt. Dort kann ich den Fehler nicht reproduzieren. Egal wie oft ich es auch versuche, die Seite ladet immer einwandfrei und ohne Probleme.
Wenn beide Seiten korrekt laden sehe ich aber auch grosse Unterschiede in den Dateien die geladen werden. Woran kann das liegen? Beim Testshop wird z.B. noch eine css2 geladen. Davon fehlt im Live Shop jede Spur (auch wenn er korrekt dargestellt wird)