mysql_pconnect() - limiter le nombre de connexions [Résolu]

[Lideln]

Bonjour à tous !

Je travaille sur un site (je suis noob en php/mysql) qui doit permettre l'inscription et la connexion de membres, la recherche (via plusieurs critères) et l'affichage des profils des membres, ainsi que l'envoi de messages type "PM".

J'ai lu sur un site qu'il fallait limiter au MAXIMUM les mysql_connect() car cette opération serait apparemment très lente côté mysql (ce site donnait un exemple : connexion 0,2sec, et simple requete 0,02sec, un truc du genre).

Donc si j'admets que j'ai environ 3000 connectés en meme temps, c'est donc potentiellement 3000 connexions et 3000 requetes a un instant donné, ce qui risque donc d'etre très très mauvais pour les perfs.

Pour l'instant (car j'ai pas réussi à faire mieux), je fais un mysql_connect() au début de chaque page qui permet de faire des requetes.

J'ai tenté une autre technique (d'où le sujet de mon post) : mettre un mysql_pconnect() dans un script que j'appelle une seule fois, mais ca marche pas.

En fait mon site est simple pour l'instant : une page index.php avec des iframes, ces iframes includant d'autres pages php, qui, elles, sont susceptibles d'utiliser la connexion à la BDD.

Voilà, si certains d'entre vous ont des conseils, voire même une solution qui a fait ses preuves pour limiter à mort les demandes de connexion à la BDD (une seule connexion pour la durée de la session serait le pied, non ?), je suis preneur

Merci à tous pour votre écoute et vos réponses

Lideln

[Alexandre T]

(une seule connexion pour la durée de la session serait le pied, non ?)

Ah non ! ce ne serait pas le pied ! On déconseille l'utilisation de pconnect ! Mieux vaut utiliser connect et couper la connexion dès que les requêtes sont traitées.


Chaque connexion active consomme des ressources. Si 2000 personnes sont en train de lire votre site, vous aurez 2000 connexions ouvertes . (Même si on suppose que vous avez répondu à la question "comment les fermer?" )

Alors qu'avec des connexions qui se ferment après le chargement de la page vous n'aurez qu'une 30 de connexions simultanément ouverte.

[Alexandre T]

N.B. : Certains logiciels comme Coldfusion gère une seule et même connexion à la base pour tout le site. Mais ce n'est pas possible en php. D'ailleurs ce n'est pas plus mal. Car en PHP/MySQL si une requête est lente, le moteur gérera par lui même pour afficher le résultats des requêtes provenant d'autres connexions.

En ColdFusion/MySQL, Coldfusion gère tout en chaîne et donc Mysql, n'ayant qu'un "client connecté" il gère successivement requête par requête.. Bon après on peut paramétrer coldfusion, mais ce n'est pas aussi simple...

[Lideln]

D'accord.

Donc en gros vous me conseillez de continuer avec une connexion par requete ? Je pensais pourtant que ca dégraderait fortement les performances....
(pour ce qui est de fermer la connexion, je suppose qu'il est possible de la fermer juste apres avoir recu la requete, avec un mysql_close() ?)

Merci pour vos indications,

Lideln

[Alexandre T]

Oui, juste après avoir reçu et traité la requête avec les mysql_fetch*().

[Lideln]

D'accord, donc je vais faire ca...
Et par souci de curiosité, ca ne dégrade donc pas les performances si 3000 connectés font une requete au meme moment ?

Merci de ton aide,

Lideln

[Alexandre T]

Si évidemment. Mes 3000 connectés qui lancent une requête ca peut correspondre à 20.000 visiteurs sur votre site à ce moment précis. Et à partir de là , il faut commencer à étudier l'architecture système pour optimiser cela également. Une simple optimisation du code ne peut plus suffir !

[Lideln]

En effet...

Et bien comme je l'ai expliqué, le site se veut une sorte de Meetic, en bien plus modeste, cela va sans dire, mais en totalement gratuit.
Les membres pourront donc faire des recherches d'autres membres selon des critères (comme age, sexe, type de relation recherchée, département), afficher ensuite le résultat de cette requete (mais ca c'est plutot côté PHP), se connecter/s'inscrire, modifier son profil, et envoyer des messages type PM aux autres membres et afficher les messages recus.
Bien sur, plus le nombre de membres pouvant surfer en meme temps sur le site et effectuer des requetes est grand, mieux c'est

Je ne sais que vous dire a propos de "l'architecture" a laquelle vous faites allusion. N'étant pas un pro (au contraire, tout jeune débutant ! ), je ne vois pas comment optimiser le tout avec "l'architecture systeme".

Qu'est ce ? Sur quoi dois je me pencher pour trouver des optimisations ?

Désolé pour toutes ces questions...

Et merci en tous cas pour vos réponses !

Lideln

[Alexandre T]

Et bien si votre site commence sur un serveur mutualisé, et qu'il connait un succès, il vous faudra alors migrer vers un serveur plus puissant voire une architecture multiserveur.

Par exemple, pour un site de grande fréquentation, il y a un serveur apache/php, un serveur d'alerte e-mail (genre envoi de mails dès que votre "client" reçoit un message privé), un serveur de mailing (newsletter, publicité), un serveurs MySQL.

[TangoZoulou]

juste une question quand tu te connecte a ta base c'est toujours avec le meme user et password?

car moi je suis dans le meme cas que toi.
je faisais ca proprement a chaque requete :

connection
requete
deconnection

sous linux ca fonctionnait bien, et je suis passé sur du win 2003 et la ou bout d'un certains temps impossible de se connecter.

je me suis renseigné sur mysql_pconnect et cette connexion re utilise une connexion qui a le meme user et password.

donc dans ce cas il n'y aura qu'une connexion

je me trompe?

[Xunil]

Bonjour,

Je suis un peu étonné de ce que j'ai pu lire dans ce post, vous conseillez une connexion par requête

On m'a toujours dit que les connexions/déconnexion étaient gourmandes en ressources, et que la bonne pratique était d'ouvrir sa connexion en début de script et de fermer en fin de script.

Si j'ai 10 requêtes dans mon code, ça me ferait faire 10 connexions/déconnexions

C'est à mon avis pas très optimisé de faire ça