nicht angemeldet
Moin!
Verwende mysql_pconnect() nur, wenn du sichergestellt hast, dass dein Datenbankserver für alle anfallenden persistenten DB-Connections zusammen ausreichend Connection-Handles anbieten kann - andernfalls schießt man sich heftigst ins Knie.
Naja... mysql_pconnect() ist nicht ohne Grund nach(!) mysql_connect() eingeführt worden.
Sicherlich mit der Idee von mehr Performance. Allerdings ist anzumerken, dass MySQL nun ausgerechnet die Datenbank ist, die sowieso recht wenig Zeit beim Connect verbrät, im Gegensatz zu anderen Varianten.
Auf Servern mit einer hohen Zahl von gleichzeitigen HTTP-Verbindungen (= hohe Zahl parallel ausgeführter Skripte mit Verbindungen zu gleichen MySQL-Server für gleichen Benutzer) kann mysql_connect auch den Effekt ("error: to many connections") haben - während dieser dann nicht aufträte, wenn in der Situation mysql_pconnect benutzt würde.
Allerdings kann man die benötigte Anzahl von durch connect() erzeugten Verbindungen sehr einfach abschätzen: Anzahl der maximal erlaubten Apache-Threads oder -Prozesse multipliziert mit 1. Denn wenn der Apache keine weiteren Prozesse erlaubt, scheitern die Zugriffe am Apachen, und nicht an der Datenbank. Das ist im Ergebnis genauso doof, aber insgesamt besser handhabbar.
Im Gegensatz dazu ergibt sich die Anzahl von durch pconnect() erzeugten Verbindungen durch die Anzahl der maximalen Apache-Prozesse, multipliziert mit der Anzahl in allen PHP-Skripten verwendeten Connection-Details (Kombination aus Server, User und Passwort).
Die klassische Kombination aus Readonly-DB-User plus Admin-User erzeugt auf dem Apachen langfristig die doppelte Anzahl an dauerhaft benutzten DB-Connections im Vergleich zu connect().
Das Ganze ist also eine Einzelfallentscheidung.
Sehr richtig. Im Einzelfall kann man sich unter Abwägung aller Randbedingungen auch mal für pconnect() entscheiden, wenn man die Seiteneffekte kennt und akzeptiert.
Grundsätzlich würde ich dagegen immer nur mit connect() arbeiten und keine persistenten Connections aufbauen.
Strato- Kunden oder solche von Hostern mit vielen Kunden auf einem Server (= verschiedene Userkennungen) sollten mysql_pconnect eher nicht einsetzen. Hat man aber wenige Kunden auf dem Datenbankserver und also viele Skripte (oder Skriptaufrufe) mit gleichen Benutzerkennungen ist mysql_pconnect klar im Vorteil: Die Frage der Performance beantwortet sich nämlich sehr wahrscheinlich ganz anders wenn man an einen entfernten statt einen lokalen MySQL-Dämon und an verschlüsselte Verbindungen e.t.c. denkt.
Das mit dem Modul steht im Handbuch - ist aber auch logisch weil der Skriptinterpreter PHP als CGI oder am Prompt ausgeführt natürlich beim Beenden nach der Skriptausführung auch alle Datenbankverbindungen schließt. Wie sollte er dann die Verbindungen offen halten?
Dein Szenario mal zusammengefasst: Im Prinzip braucht man keine persistenten Verbindungen. Bei den Massenhostern wirkt pconnect() sowieso nur wie connect(). Bei Szenarien mit vielen DB-Usern ist pconnect() in der Gefahr, die Datenbankserver zu überlasten.
Und auch das Performance-Argument ist von dir nicht mit belastbaren Zahlen belegt. Wieviel würde man mit pconnect() unter idealen Bedingungen denn wirklich gewinnen?
Darüber hinaus wäre noch zu kritisieren, dass du grundsätzlich das veraltete Modul "mysql" anwendest, und nicht "mysqli". :P
- Sven Rautenberg