S
pfffff schrieb:
warum gibst du dich mit einer antwort ohne vernünftige begründung zufrieden?
ok, ich bin lieb
pconnect ist dafuer da, wenn man sehr hohe connect kosten hat. aber in einem typischen LAMP sind die connect kosten laecherlich gering: den der apache ist n kleveres kerlchen und tut nicht bei jedem connect eine neue php instanz laden - sondern er hat selber schon pools von idlenden threads.
somit hat man im prinzip schon persistente verbindungen - nur dass eben apache darueber wacht und nicht php. und wir wissen ja: probleme am besten so abstrakt wie moeglich loesen. und apache liegt ne ebene hoeher als php.
um ehrlich zu sein: ich hatte noch nie ne situation wo man lange connect times haette.
weiters hat pconnect selber noch n paar probleme - denn php ist nicht immer faehig zu erkennen ob das jetzt die selbe verbindung sein soll, sprich er eine connection aus dem pool fischen soll oder nicht. wenn man zB nen load balancer hat, kann php da manchmal dumm drein schauen.
mysql_connect ist immer eine gute wahl. erst wenn man merkt dass das script eine signifikante zeit mit dem connect zubringt, dann kann man sich alternativen ueberlegen. aber mysql_connect funktioniert immer mit annehmbarer performance. pconnects koennen die performance des kompletten systems recht schnell in den keller bringen wenn man unvorsichtig ist (jede pconnection bleibt ja konstant offen und frisst system resourcen - sowohl auf dem client als auch auf dem server).
mysql.com sagt dazu folgendes:
Conclusion: Instead of blindly enabling persistent connections in MySQL you may wish to benchmark your application to see if persistent connections really give you the performance benefit, and if it is large enough to justify for the limitations introduced by them.