nicht angemeldet dedlfix
Rolf b
dedlfix
Rolf b
dedlfix
Der Martin
Matthias Apsel
Der Martin
moin community,
Ich habe ein Zugriff über eine Datenbankverbindung realisiert.
Ich hab mit PDO gespielt fals das ne Rolle spielt.
vlg MB
Tach!
Ich habe ein Zugriff über eine Datenbankverbindung realisiert.
- Sind mehrere Verbindungen sinnvoll?
- und solte man die Verbindung static machen da sie ja nur für ihre Funktionlität nur einmal verwendet wird.
Es ist dann sinnvoll, wenn du für deinen Anwendungsfall eine sinnvolle Begründung finden kannst.
dedlfix.
Hi dedlfix,
Ich habe ein Zugriff über eine Datenbankverbindung realisiert.
- Sind mehrere Verbindungen sinnvoll?
- und solte man die Verbindung static machen da sie ja nur für ihre Funktionlität nur einmal verwendet wird.
Es ist dann sinnvoll, wenn du für deinen Anwendungsfall eine sinnvolle Begründung finden kannst.
Ok, beispiele bei Anwendungsfällen? Und Ist das auch sinnvoll aufgrund der performance oder wenn eine schnittstelle kaputt ist das dann die andere geht?
vlg MB
Tach!
- Sind mehrere Verbindungen sinnvoll? Ok, beispiele bei Anwendungsfällen?
Mehrere Verbindungen sind dann sinnvoll, wenn du mehrere Verbindungen brauchst. Zum Beispiel, wenn zwei Systeme angesprochen werden sollen. Mehrere Verbindungen zu öffnen erzeugt mehr Aufwand. Das Öffnen einer Datenbankverbindung ist üblicherweise aber sehr schnell, so dass das meist nicht der Flaschenhals ist, selbst wenn man für jede Abfrage innerhalb desselben Prozesses eine eigene Verbindung aufbaut. (Das war jetzt aber keine Empfehlung, das so zu tun.)
Und Ist das auch sinnvoll aufgrund der performance oder wenn eine schnittstelle kaputt ist das dann die andere geht?
Wenn es kaputt ist, ist es kaputt. Da wird wohl auch keine zweite Verbindung helfen, wenn die Ursache nicht beseitigt ist.
dedlfix.
Moin,
..., so dass das meist nicht der Flaschenhals ist, selbst wenn man für jede Abfrage innerhalb desselben Prozesses eine eigene Verbindung aufbaut. (Das war jetzt aber keine Empfehlung, das so zu tun.)
Da kommt mir doch gerade was ins Gedächtnis.
Gruß Jo
Dabke für die Erklärung :) vlg MB
Hallo MB,
ob du mit PDO gespielt hast, ist weniger relevant. Das ist nur eine Hülle um den eigentlichen Datenbank-Treiber.
Wenn es mySQL war, dann möchte ich dies hier zur Lektüre anbieten. Nicht, weil ich Dir das p: Präfix unbedingt ans Herz legen will, sondern wegen der Informationen zum Verhalten von PHP ohne dieses Plugin.
Da steht, dass es im Normalfall eine 1:1 Beziehung zwischen dem MYSQL-Handle und der Netzwerkverbindung zum MySQL Server gibt. Und DAS heißt, dass ein mysqli_connect() bzw. new mysqli() einen neue TCP Connection öffnet und einen Socket auf der Client-Seite belegt. Wie schnell Sockets vom System zum Recyclen freigegeben werden, ist mir nicht ganz klar, aber auf jeden Fall ist damit einer der 32K dynamisch belegbaren Ports auf der IP belegt, auf der der Client Antworten empfängt.
Das Aufbauen einer Socket-Verbindung ist zwar schnell, aber es ist nicht zu verachten. Wenn man bspw. für jedes SQL Statement einen neue Verbindung aufmacht, kann das schnell bemerkbar werden. Vor allem, wenn der SQL Server remote läuft und nicht auf localhost.
Deswegen gibt's ab PHP 5.3 die persistent connections new mysqli("p:localhost"). Jetzt wird die physikalische Connection nach einem close nicht beendet, sondern auf Halde gelegt, bis der nächste connect kommt. Die Connection muss dann zwar intern gesäubert werden, was etwas Zeit kostet, aber das geht schneller als eine neue TCP Verbindung zu einem remote host. Das mysqlInd_ms Plugin ist dann noch eine Nummer größer, aber auch der betreibt Connection Piools.
So. Warum erzähl ich das? Weil die Frage, wie man mit Connections umgeht, von diesen Rahmenbedingungen abhängt. Mir hat ein Programmierguru mal gesagt, man müsse Connections wie heiße Kartoffeln behandeln: Nehmen, benutzen und schnell wieder fallen lassen. Der Grund ist: Tut man das nicht, dann hat man eventuell ein Ressourcenleck, wenn man den Close vergisst. Diese Regel gilt aber nur, wenn man einen Connection-Pool unter der Haube hat. Ohne einen solchen Pool ist es sinnvoller, zu Beginn eines Requests EINE Connection aufzumachen, sie die ganze Zeit zu benutzen und sich drauf zu verlassen, dass PHP sie nach Ende der Requestbearbeitung automatisch schließt.
Eine zweite Connection kann man eventuell brauchen, wenn man zwei Query-Results zusammenmischen muss. Ich hab sowas schon programmiert, weil ich kein anständiges SQL für diesen Fall gebaut bekommen habe. Und auf einer Connection kann man meines Wissens nur ein offenes Result-Set haben.
Rolf
Tach!
Wenn es mySQL war, dann möchte ich dies hier zur Lektüre anbieten. Nicht, weil ich Dir das p: Präfix unbedingt ans Herz legen will, sondern wegen der Informationen zum Verhalten von PHP ohne dieses Plugin.
Da gibt es auch noch eine eigene Handbuchseite zu Persistent Database Connections.
Um das noch etwas zu verdeutlichen: Persistente Connections hören sich super toll für einen Neuling auf dem Gebiet an. Aber das sind sie nicht. Soweit ich weiß, gilt es die Konfiguration vom Datenbankserver und PHP zu beachten und aufeinander abzustimmen. Nichts genaues weiß ich aber nicht, weil ich das Thema noch nie gebraucht habe. Das wichtigste ist, dass PHP als Apache-Modul laufen muss, sonst läuft es nicht ständig und kann keinen Connection-Pool aufrechterhalten. Als Apache-Modul will man PHP aber nur dann laufen lassen, wenn der Server nur diese eine Application zu bedienen hat. Für Konstellationen mit mehreren Websites will man lieber FCGI laufen haben und damit die Möglichkeit, jede Anwendung unter einem eigenen Nutzer laufen zu lassen.
Eine zweite Connection kann man eventuell brauchen, wenn man zwei Query-Results zusammenmischen muss. Ich hab sowas schon programmiert, weil ich kein anständiges SQL für diesen Fall gebaut bekommen habe. Und auf einer Connection kann man meines Wissens nur ein offenes Result-Set haben.
Das kann so nur passieren, wenn man ungepufferte Abfragen loslässt. Der Normalfall ist, dass das Resultset gleich beim Query abgefragt und von PHP intern zwischengelagert wird. Damit ist die Query auf dem Server beendet und eine weitere kann laufen, auch wenn man die erste noch nicht fertig-gefetcht hat.
dedlfix.
Guter Hinweis. Damals (ist mind. 15 Jahre her) steckte ich im Thema so tief nicht drin und kannte nur MS SQL Server mit C#. Da gibt's keine buffered Query wenn man sie nicht selbst buffered, und ich habe einfach die mir bekannten Patterns auf PHP übertragen.
Aber wenn die Resultsets Abfragen groß sind, dann ist eine buffered query nicht das Mittel der Wahl, weil der Buffer den PHP Speicher sprengt. Anwendungsfall wäre hier der Abgleich zweier Resultsets (z.B. Bestimmen des Deltas zweier Abfrageergebnisse, wobei die anzuwendende Logik so komplex ist, dass sie sich nicht in SQL formulieren lässt). Ich gebe zu, das ist selten und im Web-Geschäft nicht so der Hauptanwendungsfall. Eher in einem Report, der in einem Batchjob erstellt wird.
Man könnte sich in dem Fall sicher auch Gedanken machen, wie man die Queries partitionieren kann und wieder gepufferte Queries verwenden; das könnte dem SQL Server ohnehin besser gefallen (den Fall, dass die Queries unterschiedliche DBs ansprechen müssen lasse ich mal weg, dann hat man ohnehin zwei Connections).
Zu MODUL vs CGI vs FastCGI: Die PHP Doku sagt, dass persistente Connections im CGI Modus keinen Sinn machen (weil PHP nicht persistent ist) und darum nur im Modul-Modus wirken. Etliche Kommentare zur Doku sagen aber, dass PHP im FastCGI Modus durchaus persistent ist und darum auch persistente Connections funktionieren würden. Keine Ahnung ob es stimmt, ich habe nicht die Gerätschaften um das zu testen.
Wir sind hier aber in einem Grenzfall des Connectionhandlings versunken, ich weiß nicht, ob das MB noch interessiert...
Rolf
Tach!
Wir sind hier aber in einem Grenzfall des Connectionhandlings versunken, ich weiß nicht, ob das MB noch interessiert...
Es sollte zumindest soweit interessieren, dass man sich merkt: Persistente Connections klingen gut, sind aber kein Zaubermittel und erfordern Voraussetzungen. When in doubt, leave it out.
dedlfix.
Hi,
When in doubt, leave it out.
das hat unser Englischlehrer in Klasse 9 als die wichtigste Faustregel postuliert, wenn man überlegt, ob an dieser oder jener Stelle eines englischen Satzes ein Komma zu setzen wäre oder nicht.
Ciao,
Martin
Hallo Der Martin,
When in doubt, leave it out.
das hat unser Englischlehrer in Klasse 9 als die wichtigste Faustregel postuliert, wenn man überlegt, ob an dieser oder jener Stelle eines englischen Satzes ein Komma zu setzen wäre oder nicht.
FInd ich gut. Ob sich das auch auf die deutsche Sprache übertragen lässt? o.O.
Bis demnächst
Matthias
Hi,
When in doubt, leave it out.
das hat unser Englischlehrer in Klasse 9 als die wichtigste Faustregel postuliert, wenn man überlegt, ob an dieser oder jener Stelle eines englischen Satzes ein Komma zu setzen wäre oder nicht.
FInd ich gut. Ob sich das auch auf die deutsche Sprache übertragen lässt? o.O.
eher nicht, denke ich. Die Kommaregeln sind im Deutschen doch recht scharf festgelegt, auch wenn seit der Rechtschreibdeform inzwischen ein paar wenige Fälle nach Rüdiger Hoffmann[1] geregelt sind.
So long,
Martin
"Naja, gut ... das kann man machen ... muss man aber nicht ..." ↩︎
das hat unser Englischlehrer in Klasse 9 als die wichtigste Faustregel postuliert, wenn man überlegt, ob an dieser oder jener Stelle eines englischen Satzes ein Komma zu setzen wäre oder nicht.
FInd ich gut.
Die Lektore(inne)n der "The New Yorker" allerdings nicht, man nimmt es dort mit Selbstironie:
„Please, could you expel, or, at least, restrain, the comma-maniac on your editorial staff?“
