nicht angemeldet
Datenbank durch AJAX gecrasht?
Hallo und guten Abend!
Vor ein paar Tagen fragte ich hier wegen der Realisierung eines AJAX-Requests nach.
Mein Script hat getan was ich wollte und ich hab es auf den Server geladen.
Es sollte mir jede Minute einen aktuellen Datensatz einer Tabelle auslesen und dynamisch in ein html-Dokument schreiben/ersetzen.
Ich hatte die Seite noch im Hintergrund (einem anderen Tab) geöffnet und vergessen.
"Das JavaScript" holte sich also im Minutentakt einen Datensatz und aktualisierte die Seite fleissig.
Ich hab vllt. nach einer halben Stunde bemerkt, dass die Seite noch offen ist aber belies das auch dabei.
Das Script tat zu dem Zeitpunkt noch seine Arbeit.
Nach vllt. einer weiteren halben Stunde schloss ich alle Tabs und bemerkte dabei wieder jenes offene Script.
Ich dachte mir "guckste mal" und siehe da, ein MySQL-Fehler "wegen zu vielen (gleichzeitigen?) Zugriffen".
Den genauen Wortlaut weiß ich leider nicht mehr.
Ich dachte an ein temporäres und veranlasste einen Seitenreload.
Seitdem erhalte ich nur noch den MySQL-Fehler "Access Denied for user... using password[yes]...".
Die JavaScript-Funktion öffnet eine php-Datei.
Dort wird mit mysql_pconnect() die Datenbankabfrage durchgeführt.
Jetzt mache ich mir Sorgen, ob ich die Datenbank irgendwie überlastet hab.
Kann das sein?
Danke und Grüße, Matze
-
Hallo,
Jetzt mache ich mir Sorgen, ob ich die Datenbank irgendwie überlastet hab.
Kann das sein?Ja, natürlich. Ich kann doch mit PHP eine schnelle, vernünftige Ausgabe erzeugen und danach in der Datenbank rümwühlen.
Kalle
-
Hello,
interassante Sache.
Werden denn die MySQL-Requests auch irgendwann beendet und/oder die Resultsets wieder freigegeben?
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo und guten Morgen!
Werden denn die MySQL-Requests auch irgendwann beendet und/oder die Resultsets wieder freigegeben?
Mh soweit ich weiß kann ich die Verbindung mit mysql_close() nicht schließen.
Und eigentlich hab ich es auch genommen um ebend mehrere Zugriffe zu vermeiden.
In der Doku steht dazu "Erstens: vor dem Verbindungsaufbau wird zunächst versucht eine offene (persistente) Verbindung zum gleichen Host, mit dem gleichen Benutzernamen und Benutzerkennwort zu finden. Wenn das gelingt, wird die Verbindungskennung dieser Verbindung zurückgeliefert anstatt eine neue Verbindung aufzubauen."Ist das nicht performanter als jedes mal eine neue Verbindung zu initialisieren?
Ich mein, dass ich deswegen ein Problem hab seh ich ja, aber ich versteh immer noch nicht warum.Grüße, Matze
-
-
Hallo,
Die JavaScript-Funktion öffnet eine php-Datei.
Dort wird mit mysql_pconnect() die Datenbankabfrage durchgeführt.dann ist das Verhalten kein Wunder.
Jetzt mache ich mir Sorgen, ob ich die Datenbank irgendwie überlastet hab.
Kann das sein?Es ist bei Webzugriffen im Allgemeinen keine besonders gute Idee, mysql_pconnect() zu verwenden.
Freundliche Grüße
Vinzenz
-
Hallo und guten Morgen!
Es ist bei Webzugriffen im Allgemeinen keine besonders gute Idee, mysql_pconnect() zu verwenden.
Wie bereits Tom geantwortet hielt ich mysql_pconnect für performanter.
Sollte es also reichen wenn ich das "p" einfach weg lasse? Also ein "normales Connect"?
Ich hab den Provider mittlerweile erreicht und hoffe er bringt die DB erstmal wieder zum laufen. Dann ist ein "p" zu entfernen nicht mehr das Problem.
Danke und Grüße, Matze
-
Hallo,
Es ist bei Webzugriffen im Allgemeinen keine besonders gute Idee, mysql_pconnect() zu verwenden.
Wie bereits Tom geantwortet hielt ich mysql_pconnect für performanter.
Sollte es also reichen wenn ich das "p" einfach weg lasse? Also ein "normales Connect"?
Es ist eine gute Idee, Warnungen zu beachten :-)
Freundliche Grüße
Vinzenz
-
Hallo Vinzenz!
Es ist eine gute Idee, Warnungen zu beachten :-)
Mir ist schon bewusst, dass ich einen Fehler begangen habe.
Kann ich aber dem Provider eine Teilschuld geben?
Alâ "Hätte er seinen Server vernünftig konfiguriert..."?^^Nicht so ganz ernst gemeint die Frage, aber ich find den Schaden durch so ein kleines Script schon übel.
Wenn ich jetzt noch den Paranoia-Knopf anschalte, könnte man Leute ärgern indem man ihnen das Script unterschiebt und fröhlich dabei zusieht wie die DB down geht.
Grüße, Matze
-
Hallo,
Es ist eine gute Idee, Warnungen zu beachten :-)
Mir ist schon bewusst, dass ich einen Fehler begangen habe.
Kann ich aber dem Provider eine Teilschuld geben?Nein.
Alâ "Hätte er seinen Server vernünftig konfiguriert..."?^^
Hat er vermutlich. Du hast zwei rote Fenster in den Wind geschlagen :-)
Stell Dir vor, Du hättest es eilig gehabt, zu einem Termin zu kommen, hättest statt einer "grünen Welle" eine "gelb-rote Welle" gehabt und wärst zu allem Überfluss zweimal bei Rot geknipst worden. Nun fragst Du Deinen Anwalt - Du hast ja schließlich 'ne Advocard:
"Herr Liebling, kann ich nicht der Stadtverwaltung eine Teilschuld
geben? So à la »Hätte sie ihre Ampeln richtig konfiguriert ...«"Hättest Du Dein Skript vorher lokal getestet. Ja, genau mit dem dauerhaft offenen Browserfenster. Gern auch mit PHP als CGI. Es ist eine verflixt gute Idee, sich eine Testumgebung aufzubauen, die der realen Umgebung möglichst nahe kommt. Virtuelle Maschinen eignen sich wunderbar dafür.
Nicht so ganz ernst gemeint die Frage, aber ich find den Schaden durch so ein kleines Script schon übel.
Ums mit Sven zu sagen: Optimiere kein Performanceproblem, das Du nicht hast.
Freundliche Grüße
Vinzenz
-
Hallo Vinzenz!
Hättest Du Dein Skript vorher lokal getestet. Ja, genau mit dem dauerhaft offenen Browserfenster. Gern auch mit PHP als CGI. Es ist eine verflixt gute Idee, sich eine Testumgebung aufzubauen, die der realen Umgebung möglichst nahe kommt. Virtuelle Maschinen eignen sich wunderbar dafür.
Nun der Fehler trat tatsächlich auf, weil ich den Test lokal nur über max. 5 min gemacht habe.
Ich hab ganz einfach nicht mit so einem Fehler gerechnet.Nicht so ganz ernst gemeint die Frage, aber ich find den Schaden durch so ein kleines Script schon übel.
Ums mit Sven zu sagen: Optimiere kein Performanceproblem, das Du nicht hast.Bahnhof.
Grüße, Matze
-
Moin!
Hättest Du Dein Skript vorher lokal getestet. Ja, genau mit dem dauerhaft offenen Browserfenster. Gern auch mit PHP als CGI. Es ist eine verflixt gute Idee, sich eine Testumgebung aufzubauen, die der realen Umgebung möglichst nahe kommt. Virtuelle Maschinen eignen sich wunderbar dafür.
Nun der Fehler trat tatsächlich auf, weil ich den Test lokal nur über max. 5 min gemacht habe.
Ich hab ganz einfach nicht mit so einem Fehler gerechnet.mysql_pconnect() führt dazu, jeder einzelne Apache-Thread, der Webseiten ausliefert und das pconnect ausführt, eine dauerhaft bestehende Verbindung zur Datenbank aufbaut. Der Apache erlaubt in Standardkonfiguration 150 Threads parallel, nach oben ist aber kein Limit beim Konfigurieren.
Es ist nicht sichergestellt, dass der Request deines Browsers immer vom gleichen Apache-Thread bedient wird. Es wird eher so sein, dass im Laufe der Zeit jeder Thread eine eigene Verbindung zur Datenbank eröffnet.
Das bedeutet: Die Datenbank hat am Ende so viele Verbindungen offen, wie der Apache maximal Threads erlaubt. Erlaubt die Datenbank weniger Verbindungen, als es Apache-Threads gibt, wird ein Teil der Threads die DB-Verbindung nicht durchführen können. Da aber dummerweise nicht bekannt ist, welcher Thread zur Bedienung eines Browserrequests genutzt wird, kann man auch keine vorrausschauende Filterung einbauen.
Am Ende reicht schon ein einziger Browser mit regelmäßigen Requests aus, einen ganzen Server mit einem einzigen pconnect-Skript in die Knie zu zwingen.
Nicht so ganz ernst gemeint die Frage, aber ich find den Schaden durch so ein kleines Script schon übel.
Ums mit Sven zu sagen: Optimiere kein Performanceproblem, das Du nicht hast.Bahnhof.
Vinzenz bezieht sich auf mich und meine hier im Forum schon sehr häufig geäußerte Bemerkung, dass man erst dann mit Performanceoptimierung anfangen soll, wenn tatsächlich ein Performanceproblem besteht. Solange man kein Problem hat, sollte man sich immer der Standardmethoden bedienen, die überall benutzt werden.
Denn Performanceoptimierung gibt es nicht kostenlos. Sie erfordert in mehrfacher Hinsicht Aufwand (Analyse des Performanceproblems, der inneren Abhängigkeiten, Entwicklung einer geeigneten Performancemessung (nur was man in Meßwerten erfassen kann, kann man optimieren), Festlegung von "was ist optimaler" bei den Meßwerten, Entwicklung einer Umgehungs- und Verbesserungsstrategie des alten Algorithmus), und führt zwangsläufig dazu, dass der Code, der die gewünschte Funktion liefert, hinterher anders, nämlich komplizierter und komplexer, aussieht, als vorher.
Komplexerer Code ist aber schwerer zu warten, als einfacher Code. Wenn also der einfache Code die Aufgabe fast genauso gut löst, und noch kein Performanceproblem existiert, ist die Problemlösung mit dem einfachen Code immer der scheinbar optimierten Problemlösung mit komplexem Code vorzuziehen.
Denn noch etwas anderes kann passieren: Der optimierte Code könnte zwar bislang nicht real aufgetretene Performanceprobleme lösen, es können sich aber im täglichen Betrieb an ganz anderen Stellen viel eklatantere Performanceprobleme zeigen. Jetzt wird's gleich doppelt unangenehm: Es muss eine Problemlösung für dieses reale Problem her, aber gleichzeitig muss die irgendwie in den bereits schonmal vorher sinnlos optimierten und deswegen komplexeren Programmcode integriert werden. Das Resultat ist also gleich doppelt so komplex, wie es eigentlich sein müsste.
Es gibt einen schönen Spruch, der das dadurch entstehende Dilemma verdeutlicht: "Die Fehlerbehebung in einem Programm erfordert doppelt soviel Grips, wie zum Schreiben des Programms notwendig ist."
Wenn dieser Spruch wahr ist, gilt auch folgende Schlussfolgerung: "Jemand, der unter Einsatz seines gesamten Grips ein Programm geschrieben hat, kann dieses Programm nicht mehr von Fehlern befreien, weil dazu doppelt soviel Grips notwendig ist, wie er hat."
Deshalb: Programme immer so einfach wie möglich halten! Performanceoptimierungen sind erstmal nur unnötige Verkomplizierungen, die man sich solange schenken sollte, bis tatsächlich ein Problem existiert.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hallo und guten Morgen!
[...] Das bedeutet: Die Datenbank hat am Ende so viele Verbindungen offen, wie der Apache maximal Threads erlaubt. Erlaubt die Datenbank weniger Verbindungen, als es Apache-Threads gibt, wird ein Teil der Threads die DB-Verbindung nicht durchführen können. [...]
Danke für die ausführliche Erklärung!
Am Ende reicht schon ein einziger Browser mit regelmäßigen Requests aus, einen ganzen Server mit einem einzigen pconnect-Skript in die Knie zu zwingen.
Hab ich gemerkt und kann es jetzt auch nachvollziehen, danke!
Es gibt einen schönen Spruch, der das dadurch entstehende Dilemma verdeutlicht: "Die Fehlerbehebung in einem Programm erfordert doppelt soviel Grips, wie zum Schreiben des Programms notwendig ist."
Das leuchtet ein und kommt in die selbe Sparte wie "Never change a running system" &co ;)
Wenn dieser Spruch wahr ist, gilt auch folgende Schlussfolgerung: "Jemand, der unter Einsatz seines gesamten Grips ein Programm geschrieben hat, kann dieses Programm nicht mehr von Fehlern befreien, weil dazu doppelt soviel Grips notwendig ist, wie er hat."
Mh aber nur rein mathematisch betrachtet. Theologisch gesehn ist der Mensch zum Glück in der Lage dazu zu lernen (ja auch aus Fehlern^^).
Träfe das Beispiel zu, würde auch das simmen (müssen):
3 Leute betreten eine Bahnhofs-Toilette, nach einer Weile kommen 4 raus.
Wenn jetzt noch einer rein geht, ist keiner mehr drin. :)Performanceoptimierungen sind erstmal nur unnötige Verkomplizierungen, die man sich solange schenken sollte, bis tatsächlich ein Problem existiert.
Dürfte ich dann aber nochmal ganz naiv nach einem praktischen Beispiel fragen, in dem ..._pconnect() sinnvoll wäre?!
Danke und Grüße,
Matze
-
-
-
-
-
-
-
-
Hi,
Jetzt mache ich mir Sorgen, ob ich die Datenbank irgendwie überlastet hab.
hast Du die Warnung gelesen?
"Die Verwendung von persistenten Verbindungen verlangt unter Umständen eine feinere Abstimmung der Konfiguration von Apache und MySQL. Dadurch sollten Sie sicherstellen, dass Sie die Anzahl der Verbindungen, die MySQL maximal erlaubt, nicht überschreiten."Darüber hinaus werden noch einig Gründe angeführt, die gegen "p" sprechen...
Gruesse, Joachim
--
Am Ende wird alles gut.