nicht angemeldet
Tach!
Ich muss trotzdem jedes mal den Datenbankserver nach der Verbindung fragen.
Mit anderen Worten: Das spart keinerlei Code. Es kommt sogar noch hinzu, dass man das Persistenzattribut angeben muss.
Ich glaube, es ging MB nicht darum Code zu sparen, sondern die Effizienz zu steigern. Das eine Attribut mehr scheint mir für die geforderte Funktionalität die Lösung mit dem wenigsten Code zu sein. Oder hast du noch eine andere Idee, die mit weniger auskommt?
Der Verbindungsaufbau ist vernachlässigbar, wenn nicht gerade eine sehr langsame Netzwerkverbindung zwischen Webserver und DBMS besteht. Da lässt sich durch Netzwerkoptimierung mehr sparen. Zumal ein langsames Netzwerk ja auch auf Query- und Ergebnisübertragung wirkt.
Und dass das ganze sowieso nur funktioniert, wenn PHP als Modul im Apachen läuft (IIS und andere Webserver nicht betrachtend). Im Modul zu laufen, hat Nachteile in Webservern, in denen mehr als die eine Anwendung laufen soll, wie schlechte oder keine Separierbarkeit.
Bist du da sicher? Das Handbuch sagt etwas anderes. Nur PHP als CGI scheint ein Problem zu sein, aber hat das heutzutage noch Relevanz?
Bei CGI wird für jeden Request ein Prozess gestartet und beendet. Da gibts nichts, was eine DBMS-Verbindung offenhalten könnte.
Bei den Formen FCGI und FPM fehlt mir das Wissen, wie lange der Prozess bestehen bleibt und damit auch evenuell geöffnete Verbindungen. Da in diesen Szenarien mehrere PHP-Instanzen nebeneinander laufen, muss dann aber auch jede eigene ihre eigenen Verbindungen verwalten. Das hat dann keinen Effekt wenn der nächste Request an einen anderen Prozess im Pool geht, der die Verbindung noch nicht geöffnet hat. Es sei denn, die Verwaltung der Verbindungen kann von der Poolverwaltung übernommen werden. Da die Vorteile persistenter Verbindungen aber nicht wirklich merkbar sind, hab ich mich damit nicht weiter beschäftigt.
dedlfix.
Matthias Apsel