Nach Submit-Button hängt diese Seite

[Schumiel]

Hallo,

und zwar bin ich per Serverumzug zu 1und1 (Managed Server) gewechselt. Auf dem neuen Server haben meine User die Probleme, wenn sie auf einen Submit-Button klicken, dass die Seite 5-10 Sekunden so bleibt wie sie ist und im Browserstatus "Warten auf domain.de" steht. Erst nach diesen 5-10 Sekunden ändert sich die Seite.

Woran kann das liegen?
Etwas an der php.ini einstellen?

 

[Speedy.]

Glückwunsch, du hast zu einem der schlechtesten Hoster überhaupt gewechselt. Ich betreue eine Webseite für einen Kunden auf 1und1 und habe regelmäßig Probleme, weil der Server limitiert (es kommen PHP-Fehlermeldungen, weil nicht genug Speicher vorhanden ist - von zugesicherten 64MB werden nur 8MB wirklich gegeben).

Meine Empfehlung - nichts wie weg von dem Verein. Wenn dein Skript vorher oder lokal bei dir gut funktioniert, dann weißt du dass es an denen liegt. Da kannst du per php.ini auch nicht viel erreichen.

 

[Schumiel]

Nun ja, ob es der schlechteste Hoster ist, kann man sich sicherlich drum streiten. Bisher bin ich sehr zufrieden. Und nur weil es ein Problem gibt, muss man nicht gleich wieder wechseln.

Das Problem am Problem ist, dass ich den Fehler bei mir selbst nicht reproduzieren kann, sondern von 1000 User ca. 100 User trifft, die dieses Problem und wie beschrieben geschildert haben.

 

[John Reese]

Wenn es ein bestimmtes Skript bzw. eine bestimmte Seite ist, dann müsste man schon den Code dazu sehen...

 

[Schumiel]

Es ist keine bestimmte Seite, sondern betrifft viele Seiten mit einem Submit-Button. Es passiert auch unregelmäßig.

 

[John Reese]

Dann könnten es Lastspitzen (?) oder Ähnliches sein..

Ich hab auch schon "komische" Probleme mit 1blu erlebt: das Routing zu deren Server(n) war zumindest damals grottig.

Also: evtl. ein Routing-Problem?

Ganz sicher, dass das nur bei Formularen nach dem Abschicken passiert?

 

[Schumiel]

Ob ich mir sicher bin? Hm. Bisher melden meine User nur, dass es nur beim Abschicken eines Formulars auftritt.

 

[Daaron]

Es ist ganz einfach: Vorher hattest du das Problem nicht, oder? Jetzt hast du es. Also liegt es am neuen Hoster.
Da die Seite GRUNDSÄTZLICH funktioniert, liegt hier offensichtlich ein Leistungsproblem vor. Irgendwo hängt das Script, dass deinen Submit-Knopf verarbeitet. Wenn das vorher bei ähnlicher Besucherzahl nie der Fall war, dann muss also an deinem Managed Server was nicht stimmen:

- der Datenbank-Server (da dein Submit ja sicher irgendwas mit der DB macht, egal ob lesend oder schreibend) ist vielleicht arschlahm. Liegt die DB wenigstens auf "localhost", oder machst du ne Connection zu ner externen IP?
- deine PHP-Implementierung ist arschig lahm. Evtl. hat sie keinen OpCode-Cache. Evtl. läuft so ein Rotz wie suPHP. Evtl. läuft ne lahmarschige CGI-Krücke. Oder, was auch denkbar ist, es läuft zwar ne eigentlich ordentliche Konfiguration (PHP-FPM), aber selbige stößt direkt an ihre Leistungsgrenzen, weil CPU, RAM oder I/O (Festplatte) krepieren
- Du erzeugst viele Session-Files und der Submit löst evtl. gelegentlich den Garbage Collector aus. Managed Server -> virtueller Mist -> lausiges HDD-Performance -> PHP hängt bei der Garbage Collection

Such dir einen anständigen Hoster. Spiel nicht mit virtuellen Servern herum, auch nicht mit Managed Server Lösungen. Wenn du mehr Power brauchst, dann schau dich nach einer guten Cloud Hosting Lösung um, z.B. AWS. Da hast du so viel Power, wie du benötigst (und bezahlen kannst).

 

[Schumiel]

Hm, ich denke eher, dass paar SQL-Queries zu lange brauchen könnten. An eine my.cnf kommt man bei einem Managed Server nicht ran oder?

 

[Daaron]

Wenns die Queries wären, dann würde es jedes Mal hängen.

 

[Schumiel]

Nein. Die Queries sind von Seite zu Seite unterschiedlich und die langen Ladezeiten treten ja nur auf bestimmten Seiten auf.

Mit dem Serverumzug musste ich generell schon einige Queries umändern oder mit index optimieren. Der Server ist halt schlechter - bewusst so gewählt. Daher wäre mir slow-queries-log eine große Hilfe. Aber kommt man bei Managed Server an sowas ran?

 

[Daaron]

Frag nicht uns, frag den Betreiber.
Aber warum sollte man leistungsmäßig einen Rückschritt machen? Wirklich mächtiges Hosting ist in Deutschland doch für Peanuts zu haben. Wenn man die nötigen Kenntnisse mit bringt, kriegt man für 30-40€/Monat sogar n kompetten (und fetten) Dedicated...

Schau halt mal nach, ob du zumindest Zugriff auf "SHOW STATUS" hast, da siehst du zumindest einiges an Leistungsdaten deiner Queries. Du siehst, wie viele Slow Queries es gibt, wie gut (oder schlecht) dein Query Cache läuft und wie gut dein RAM auf wiederholt geöffnete Tabellen reagiert.

Wenn es am Ende wirklich an Slow Queries hängt UND du zusätzlich noch RAM übrig haben solltest, dann schreib dir eine Memcached-basierte Caching-Lösung für diese Queries.

 

[Schumiel]

Aber warum sollte man leistungsmäßig einen Rückschritt machen?

Ich hatte einen Root-Server. Da ich keine Zeit mehr habe, diesen zu administrieren, von meinen laienhaften Kenntnissen ganz zu schweigen, habe ich mich für einen Managed Server entschieden. Da Managed Server im Verhältnis zu einem Root-Server mehr Geld kosten, musste ich für den gleichen Preis eben Server-Leistungsabstriche machen.

Schau halt mal nach, ob du zumindest Zugriff auf "SHOW STATUS" hast, da siehst du zumindest einiges an Leistungsdaten deiner Queries. Du siehst, wie viele Slow Queries es gibt, wie gut (oder schlecht) dein Query Cache läuft und wie gut dein RAM auf wiederholt geöffnete Tabellen reagiert.

Danke für den Tipp. Darauf habe ich Zugriff. Auch hat mein Serveranbieter bereits slow_queries_log freigeschalten.

Wenn es am Ende wirklich an Slow Queries hängt UND du zusätzlich noch RAM übrig haben solltest, dann schreib dir eine Memcached-basierte Caching-Lösung für diese Queries.

Hier kann ich dir leider nicht mehr folgen. Das ich allgemein das Problem nicht gelöst bekomme, frustriert mich sehr. Vor allem auch, weil es bei mir keine langen Ladezeiten gibt und auch wenn ich den Server mit "top" eine Weile beobachte, nicht einmal die CPU über 10% geht.

Edit: Wenn ich memory_limit abchecke, ist bei 153M schluss. Dürfte doch aber auch ausreichen?

 

[Daaron]

Memcached ist nicht vom PHP Memory Limit betroffen. Memcached ist ein eigener Dienst, der eben, wie der Name verrät, einen flüchtigen Key-Value-Store im RAM anlegt und für den es allerhand Schnittstellen und Anwendungsmöglichkeiten gibt. Ich nutze Memcached z.B. grad als replizierender Session-Speicher auf einem Loadbalancer-Setup.

Was du also machen KÖNNTEST:
Wenn es immer wieder dieselben Queries sind, die so lahmarschig sind, und die Ergebnisse sich auch nicht unterscheiden (bzw. erst nach ner Weile), könntest du einen Hash des Queries als Key und das Ergebnis des Queries als Value nehmen.

Im Endeffekt ist hier aber der reguläre Query Cache der Datenbank deutlich besser. Schau also, ob selbiger genug Dampf unter der Haube hat. Außerdem: Indizes optimieren und evtl. die Engine wechseln.

Vor Jahren hatte ich mal n ziemlich komplexen Query mit vielen Joins auf ner riesigen DB und ner arschlahmen Kiste. Habs am Ende darauf runter gebrochen, dass ich periodisch Teile des Queries ausgeführt habe und die Ergebnisse in ne Memory Tabelle geschrieben hab. Danach habe ich die Ergebnisse einfach verknüpft.
War ziemliches Code-Chaos, aber hat die Query-Laufzeit gedrittelt, nachdem sich der Cache erst einmal etwas gefüllt hatte.

 

[ice-breaker]

Hatte ich mit einem Kunden auch schon, der unbedingt zu 1und1 wollte: abundzu hat der MySQL-Server einfach am rad gedreht und die simpelsten SQL-Queries haben gefühlte Jahre gebraucht. Ich hatte das dann irgendwann angefangen zu protokollieren und es in nem Graph dargestellt - hatte wirklich ein festes Muster. Die Grafik hate gereicht, dass der Kunde wieder wechselt.

 

[Schumiel]

Danke für eure Antworten. *daumen hoch*

Vielleicht sind es doch nicht die SQL-Abfragen? "SHOW PROCESSLIST" habe ich gestern Abend mal fast sekündlich aktualisiert und da blieb nie etwas länger hängen, außer mal das sleep. Auch die Server-CPU bringt es nie über 10%. Ich habe leider auch viele Inner Joins und ich denke, dass ich mich hier mehr als zuvor mit Indizes optimieren auseinandersetzen muss, als ich befürchtet habe.

Nachdem ich nun die Scriptlaufzeit pro Seitenaufruf messe, fällt mir auf, dass die Ladezeiten bei relativ vielen Usern immer nur bei exakt 5 oder 12 Sekunden sind. Zugegeben, diese 5 Sekunden gab es auch auf den alten schnelleren Root-Server, aber nicht so in der (User-)Masse und Häufigkeit. Aber warum diese zwei Werte?

Ergänzung (22. Oktober 2014)

außer mal das sleep

Ich habe wohl den Übertäter gefunden.

145691 ... localhost ... Sleep 5

146123... localhost ... Sleep 11

... kommen sehr häufig vor und brechen oft nach 5 oder 12 Sekunden ab.

 

[Daaron]

Aber... Sleep tut doch nix, außer n Slot im Connection Pool zu belegen...

Wenn du sehr viele Sleeps hast, dann schließt du Verbindungen nicht anständig.

 

[Schumiel]

Stimmt, daran liegt es wohl nicht.

Ich hatte diese lange Ladezeit nun heute endlich das erste Mal.
Es ist so, wenn ich auf ein Link klicke, passiert nichts (diese ominösen 5 Sek.), außer das im Tab "Verbinden..." steht und in der Browserstatusleist "Warten auf domain.de".

Ich weiß einfach nicht mehr weiter!

 

[Daaron]

Na ja, wenn dein Connection Pool an irgend einer Stelle ausgereizt ist, würde genau das passieren. Angenommen, du hast so viele Sleep-Prozesse im MySQL, dass ein neuer Seitenaufruf keine DB-Connection herstellen kann -> PHP würde warten bis irgend ein Schläfer vom Timeout gemeuchelt wird (oder selbst in den Timeout rutschen).
Genauso könnte Apache grad keine freien Connections haben oder, wenn es PHP-FPM ist, könnte kein freier PHP-Worker übrig sein, weil der Pool viel viel zu mickrig dimensioniert wurde.
Vielleicht hast du auch I/O - Ops, die irgendwo lange dauern und die Festplatte blockieren. Dann könnten Apache und PHP ihre Files nicht laden -> Warteschleife.

Frag deinen Hoster mal, ob er dir ein Werkzeug wie Munin installieren kann. Ich mag Munin, da kann man so schön Lastspitzen verfolgen, vor allem I/O-Spitzen (z.B. vom monatlichen Re-Sync des mdadm-Cronjobs) sieht man sehr deutlich.

 

[Schumiel]

Fehler gefunden!!

gethostbyaddr($_SERVER['REMOTE_ADDR']);

Warum versucht das die 5 und 12 Sekunden Ladezeit?