Unterschied zwischen persistenten und nicht-persistenten Verbindungen?

[haarrrgh]

Der Titel sagt eigentlich schon alles - es geht um den Unterschied zwischen persistenten (mysql_pconnect) und nicht-persistenten (mysql_connect) Verbindungen.

Den eigentlichen Unterschied glaube ich schon verstanden zu haben, denn das scheint im wesentlichen folgender, von hier zitierter Satz zu sein:

"Die Verbindung wird nicht mit dem Beenden des Skripts geschlossen, sondern bleibt bestehen für einen zukünftigen Verbindungsaufbau."


Mir ist nur noch nicht so ganz klar, ob ich das brauche oder nicht. In welchen Fällen ist es denn nützlich, daß die Verbindung beim Beenden des Skripts offen bleibt?

[c4]

Ich zitiere mal aus dem Kundenforum von HostEurope:

Original geschrieben von Felix Schüren
Es gibt viele Quellen (und leider auch Programmierer), die generell empfehlen sog. "beständige Verbindungen" (persistent connections, pconnects) zum Datenbankserver aufzubauen. Der reguläre "connect()"-Befehl in PHP schliesst die Verbindung automagisch bei Beendigung des Skriptes, "pconnect()" tut genau dies nicht - die Verbindung bleibt bestehen.

In speziellen Einsatzgebieten - ein dedizierter Server mit einem (genau einem!) grossen Forum beispielsweise - kann das Sinn machen, weil die Verbindung beim Start des nächsten Skriptes nicht erneut aufgebaut werden muss, man spart so einige Millisekunden. Im Shared Hosting erzeugen pconnects aber ein grosses Ressourcen-Problem - sie sind nicht Skript-, sondern Webserverbezogen, und der Webserver ist für hunderte von Domains zuständig, die alle auf verschiedene Datenbanken zugreifen. Die Wahrscheinlichkeit, dass eine persistente Datenbankverbindung wieder genutzt werden kann ist ca. 1/(anzahl Präsenzen) (bei gleicher Lastverteilung) und tendiert somit stark gegen Null.
Gleichzeitig hält aber der MySQL-Server die Verbindungen bis zum Erreichen eines Inaktivitäts-Schwellenwertes offen und schwillt so sehr schnell auf ein vielfaches der tatsächlich benötigten Prozesse an.

Ein kleines Beispiel:

- Shared-Hosting-Server mit 100 Präsenzen (P)
- 20 Webserver-Instanzen (I) stehen zur Verfügung
- der pconnect-timeout auf dem SQL-Server beträgt 10 Minuten
- jede Präsenz hat 1 Besucher (B) pro Minute.
- jede zweite Präsenz nutzt pconnects
- nur jeder hundertste Aufruf kann den pconnect nutzen, wird in der Rechnung vernachlässigt

Das wären also 50 pconnects / minute, mithin immerhin 500 connections insgesamt. Für jede connection muss ein Prozess auf dem SQL-Server laufen. Nach 10 Minuten ist dann erstmal das Limit erreicht, die ältesten pconnects werden vom SQL-Server geschlossen. Die Prozesszahl pendelt sich also bei konstanten 500 ein.

Für die normalen Connects sieht die Rechnung wie folgt aus:

50 connects/minute, werden sofort wieder geschlossen, macht max. 50 Prozesse gleichzeitig, in der Praxis wesentlich weniger da gleichzeitiger Zugriff sehr selten ist.


Wie gesagt, pconnects können auf einem dedizierten Server sinnvoll sein, im Shared Hosting schaden sie nur extrem.

Cheers,

Felix