Minimiser la connexion MYSQL avec le MVC.

[vol-au-vent]

Bonjour !

Avant de commencer à coder le php de mon site j'aimerais quelques conseils afin d'éviter trop de connexion à une BDD avec le MVC et en AJAX (Donc il n'y aura pas de rechargement de page).

Après authentification > Une connexion à la BDD pour récupérer le statut / les variables du personnage > déconnexion.

Onglet message > Connexion à la BDD pour récupérer les 20 derniers messages > déconnexion.

Ect.. pour chaque onglets.

Enfin je sais pas vraiment si c'est la bonne solution mais j'aimerais savoir optimiser ça pour ne pas avoir de problèmes avec mon hébergeur !

Je vous remercie pour vos réponses et votre aide =)

[Sephi-Chan]

Garde la connexion à la base ouverte tout le temps de la requête. Établir la connexion avec le serveur MySQL est souvent ce qu'il y a de plus long.

[vol-au-vent]

D'accord donc quand j'ouvre un onglet du jeu (exemple : messagerie), je me connecte, je fait mes requête et une fois que tout est bon je me déconnecte ?
Je pensais qu'il y avait d'autres façon de minimiser et d'optimiser ça afin de ne pas avoir trop de connexions.
Merci je vais faire comme d'habitude alors !

[Sephi-Chan]

La connexion se ferme implicitement a la fin d'un script.

Tu peux la fermer plus tôt si tu es sûr de ne plus en avoir besoin et qu'un traitement long intervient ensuite.

[Xenos]

Tests personnels sur la connexion PHP / MySQL

Ca date un peu, et les protocoles de tests sont pas top... Mais l'idée générale y es.
► Procéder toujours en deux temps: 1 phase de récupération des données de la BDD, phase où on est connecté, et une deuxième phase de traitement des données, où on est totalement déconnecté de la BDD
► Fermer la connexion MySQL dès que possible si on atteint la limite de connexions simultanées (pour limiter la famine des clients)

Si tu procèdes en 3 temps (SELECT / traitements PHP / UPDATE), alors suivant la durée du traitement, il peut être intéressant de fermer la connexion MySQL.

Mais l'alternative que j'adore pour éviter ces connexions / déconnexions multiples, c'est la mise en cache \o/
Sur le principe, étant en mutualisé:
► Je me connecte à la BDD, je lis toutes les données concernant le joueur
► Je ferme la connexion à la BDD
► Je sauve les données dans un document XML
► Le client utilise le document XML au lieu de la BDD
Ok, les données du XML ne sont pas exactement celles de la BDD, mais si ces données sont un tant soi peu statiques ou volumineuses (email, pseudo, messages, statistiques...) alors le gain est fort

[vol-au-vent]

Je te remercie pour tout ça, je n'aime pas trop la mise en cache car l'utilisateur peut modifier le cache par contre je n'avais pas penser à l'écriture dans un fichier !

[Xenos]

Par "cache", j'entends pas le cache coté client (de toute façon, un bon site web n'a pas à s'en préoccuper, c'est le boulot du navigateur web), mais le "cache" coté serveur, ici l'écriture dans un fichier

Mais attention: c'est une opération lourde que d'écrire un fichier sur le HDD, donc faut pas non plus en abuser.

[Sephi-Chan]

J'en profite pour te mettre en garde contre l'optimisation prématurée : ne pense pas à optimiser quelque chose qui n'est pas fonctionnel. Si tu n'as encore rien codé, il est trop tôt pour penser à le rendre plus rapide.

1. Make it work
   
2. Make it right
   
3. Make it fast
   

[Xenos]

+1 !

Mais... "make it right", c'est à dire?

[niahoo]

Debug, simplifier les algos, refactorer, etc.

---

L'idée est qu'il est mille fois plus simple de faire du beau code, propre et élégant une fois qu'on peut le tester, ce qui implique de passer de temps en temps par un algo un peu plus brut.