hi,
Moin!
ich habe mich sehr lange das selbe gefragt.
Nachdem ich aber einige Zeit lang eine Anwendung mit ca. 2000 Usern pro Tag hatte, wurde mir der Sinn leider schmerzlicher bewusst.PHP räumt zwar in der Tat selber auf, braucht aber grade in Verbindung mit Datenbanken häufig etwas zu lange. Dadurch kann es dazu kommen, dass zuviele Verbindungen offen sind und eventuelle LOCK befehle den rest aufhalten könnten.
Mit der Methode kannst du dann explizit immer sagen, dass die Verbindung beendet werden soll.
Wenn das deine Lösung war, war's keine gute Lösung. Destruktoren werden ja nur implizit aufgerufen, und irgendwann nach dem Löschen der letzten Variablen, die auf das Objekt zeigt.
Wenn du ein Connection-Problem mit der Datenbank hast, würde ich mich fragen, wieviele Prozesse/Threads/Scriptparallel-Läufe der Webserver erlaubt. So viele Connections muss die Datenbank abkönnen.
Nehmen wir mal kleine Zahlen um einfach zu rechnen:
5 Prozesse gleichzeit, DB erlaubt z.b. 14 Connections ohne zu zucken.
Nun schließen die ersten 5 Prozesse nicht schnell genug und die nachfolgenden 5 machen auf. Somit haben wir in dem Moment 10 Connections "offen".
Nun machen wir das ganze noch mal und bemerken, dass die 15. Connection ein Problem haben dürfte.
Bei 2000 Spielern die alle 5 Sekunden klicken kommst du auf 40.000 Anfragen.
Dann nehme noch einen Server von vor einigen Jahren dazu und du wirst darauf stoßen.
Dann noch bei Nachgeladenen Informationen und du bist schnell bei 80-100k Anfragen.
Zugegeben: Man kann mir hier vorwerfen, das ganze unterschätzt zu haben. Aber wer erwartet schon so einen ansturm in kürzester Zeit?
Sicher man könnte die DB-Verbindung auch dort schließen, wo man die ganze Ausgaben raus schmeißt. Es könnte aber dann auch mal vergessen worden sein und trotzdem wird es noch getriggert. (Soweit keiner im destructor von anderen klassen noch ein exit() verwendet.)
Es gibt natürlich einige andere Möglichkeiten solche Probleme zu vermeiden. In der Not ist es aber die Lösung gewesen und innerhalb kürzester Zeit machbar. Ob es die schönste Lösung ist, war hier ja auch nicht gefragt, Sinnvoll war es aber allemal, denn das System lief dadurch wieder!
Wenn's hingegen ein Problem mit dem Locking ist: Ja, Locks sollte man freigeben, wenn man sie nicht mehr braucht...
Was man eigentlich direkt im Script auch tun sollte, wo man die Locks setzt. Selbst bei Fehlern sollte das durch try&catch ja möglich sein ...
Für Logging müsste das ganze übrigens auch funktionieren, da man so z.b. noch einen finalen "bin durch gelaufen" Eintrag hinterlassen könnte! Die Dateistreams werden ja auch erst danach geschlossen und nicht schon davor!
Ich würde mich persönlich nicht drauf verlassen, dass man im Destruktor einer Klasse noch was loggen könnte. Da ich aber derzeit keinen einzigen Destruktor in meiner Codebasis habe, weil PHP alles korrekt selbst wegräumt, ist das ein unbedeutender Effekt.
Einzig die Ausgabe funktioniert nicht mehr. Also Echo usw. wird nie erfolg haben.
Das hängt eindeutig davon ab, wann ein Destruktor getriggert wird. Am Scriptende sicherlich nicht.
Wenn man die Objekte zur Laufzeit selber löscht (an diesen Fall habe ich bei meiner Aussage nicht gedacht), dann werfen diese natürlich sichtbare echos ...
- Sven Rautenberg
Gruß Niklas
Man muss nicht alles wissen, man sollte aber wissen, wo das nicht gewusste zu finden ist.