Version imprimable
Alors pour savoir si je suis dans le bon, dites moi combien de requête est il idéal de faire AU MAXIMUM pour un site accueil des centaines de personnes simultanément.
Les données présentées ne permettent pas de résoudre un tel problême précisement.
Un peu comme berceker, je dirais entre 0 et 50.
Par contre, a l'inverse de berceker, je ne voie pas comment est-il possible de faire 10 requêtes plus optimisables qu'une seule.
C'est une question de cycle de processus. En fait, je discutais avec des programmeurs qui développe pour les cpu intel pour base de données. Il me disait que bien souvent. Il est préférable de découper une grosse opération en plusieurs morceaux. La grosse opération va mobiliser le cpu une intervalle de temps plus grande par personne, les autres vont être en attente. Le découpage d'un grosse opération fait que chaque personnes va être servie par petit bout ça va prendre un peut prendre le même temps voir moin mais tous le monde sera servie. Bien évidement ça ne marche pas a tout les coups. Il y a beaucoup de paramètre à prendre en compte avant de jouer à ce jeux là.Citation:
Envoyé par is_null
Exemple perso en php. J'avais une boucle while qui par boucle executait une grosse opération. Lors de mes test : pas de problème puisqu'il y a un seul client. J'ai balancé 10 clients sur la même opération, le resultat était catastrophique. J'ai résolu le problème en plaçant un unsleep(...) dans la boucle. C'est con mais le faite de placer une micro pause sur chaque boucle a fait que les perf était "amazing" !:yaisse2:.
Depuis que je suis au courant de se phénomène j'ai créé en php une gestion de performance. Entre le nombre de processus ouvert et le nombre d'occurence.
Est ce qu'il ya une différence de performance entre les instructions mysql_connect, mysql_query & mysqli_connect, mysqli_query (sous l'hypothèse qu'on se connecte à une version récente de mysql) ?
Dans le cas où on utilise l'extension mysqli, vaut-il mieux utiliser des mysqli_query ou un mysqli_multi_query ?
C'est pas tellement de l'optimisation ça. Il s'agit de bien faire la différence entre
- Le nombre de requêtes traîtées par secondes
- Le temps qu'il faut pour traiter une requête
On peut traiter les requêtes qui arrivent en même temps une par une. La première sera servie en un temps X, la seconde probablement en 2X, et la dernière attendra extrèmement longtemps. En termes de temps de réponse c'est très mauvais.
Pour le usleep, s'il était nécessaire, il est probable que l'OS soit mal configuré. En principe ce n'est pas le code qu'on modifie pour améliorer ça. Il y avaut un lien dans ce sujet qui montrait un site intéressant parlant de l'importance de la configuration du serveur. Le site tentait d'étudier la question d'optimisation de code toute en précisant bien que c'était très modeste, et en tout cas secondaire dans la liste des optimisations.
La réduction de parallélisme sur une grosse opération peut être dûe aux verouillages. Sur des opérations dispersées, un verouillage en deux phases permet potentiellement un meilleur parallélisme.
Merci pour ces precisions berceker.
Toutefois, je pense que ce sera obsolete pour MySQL quand la 5.1 sera stable (pour l'instant inutilisable en production), particulierement grace au partionnage de tables natif 8-)
Je me suis pas intéressé sur le partionnement de table. Je vais y jeter un oeil dans ce domaine pour savoir si ça va me servire ;) !Citation:
Envoyé par is_null
Je suis daccord, le problème c'est que, comme moi, quand tu fais une application dont tu ne sais pas sur quoi ça va être posé. Bien evidement, il faut pas mettre des usleep partout. Le plus important dans la programmation c'est de ne pas tomber dans la paranoïa ! ;)Citation:
Envoyé par Blustuff
Peux-tu préciser ce passe?Citation:
Envoyé par Blustuff
Ceci m'intéresse :)
Un process à ouvert un objet et personne d'autre peut utiliser cette objet tant que le process ne l'a pas libéré. Quand je parle d'objet c'est totalement abstrait dans le domaine de l'os. En SQL tu peux avoir fait une opération sur une table, la table sera vérouillé sur cette opération. Personne d'autre peut faire une opération sur cette table tant qu'il n'est pas libéré. Donc quelque part tu fais la queue comme tous le monde sleep() ou pas.Citation:
Envoyé par Sayrus
Citation:
Envoyé par berceker united
Donc cette méthode n'est pas la meilleure niveau optimisation si j'ai bien compris?
si 100 requêtes sont effectuées en même temps, alors elles doivent attendre leur tour, et la dernière devra attendre très longtemps...
Dans l'exemple de mysql oui. Mais mysql a des fonctionnalité assez complète pour gérer le vérouillage. Par exemple, là ou j'estime que c'est pas problématique j'utilise le LOW_PROPERTIES. il ecrit dans la table quand elle est libéré. Bon, c'est un sacré sujet de lock de table. Personnellement, je pense y jouer mais en mettant un maximum de précaution parce qu'une erreur peut planter toute ton application :/Citation:
Envoyé par Sayrus
Bonjour,Citation:
Envoyé par hachesse
J'ai fais un site php où tous mes liens renvoient vers la page index.php mais avec des contenus(includes) différents..
Pour l'instant , dès que j'ai besoin de ma BD , j'ouvre la connect , j'envoie la requete puis je ferme..
Serais-ce plus optimal d'ouvrir la connexion au démarrage de la SESSION et de fermer la connexion à la BD lors de la fermeture de session?
Je n'ai pas , au premier jet , employé cette technique , car je me suis dis que l'utilisateur risquerait de garder la connex à la BD assez longtemps , je ne sais pas si c'est problématique ou non..
Merci de votre aide
Salut
Tu es en train de proposer exactement le contraire de ce que recommande hachesse. Tu voudrais ouvrir une connexion permanente, mais de nombreuses discussions à ce sujet déconseillent cette approche.
C'est le pourquoi du comment je n'ai pas fais celà..Citation:
Envoyé par Yogui
Je reformule ma question alors :
Est-ce mieux d'ouvrir et fermer la connexion à chaque page ? (genre debut du body = connex , fin du body = deco)
ou alors l'ouvrir et fermer uniquement lorsque j'en ai besoin ? (ce qui signifie que parfois je ne l'ouvrirai pas , parfois je l'ouvrirai/fermerai plusieurs fois par page)
Le mieux est d'utiliser des connexions éphémères, car les connexions peristantes subissent le gros problème d'Internet : on n'a aucun moyen fiable de déterminer quand l'utilisateur est inactif, absent, etc. Donc pas de connex persistantes, mais apparemment tu le sais déjà.
Restent les connexions éphémères.
Le plus simple est de ne jamais fermer manuellement la connexion : PHP s'en chargera lui-même en terminant l'exécution du script. Évidemment, réouvrir une connexion fermée dans un même script est une énorme perte de ressources.
En fait la plus part des providers ou hébergeurs si tu préféres , mettent à disposition des bases mysql avec un certain nombre de connexion simuatanées.Citation:
Envoyé par libuma
48 : pour INFOMANIAK ( exemple ) .
si tu conserves les connexions tu risques d'avoir un message du type server busy !!
Généralement on ouvre la connexion , puis un éxécute la requête puis un fois que l'on a son résultat on fait un close sur la connexion .
a+
une chose est sure , on évite les connexions persistantes alors ^^
pour le reste , vous m'avez donné deux versions différentes :(
Mais bon , merci de votre aide :king:
Fermer manuellement la connexion au plus tôt s'appelle de l'optimisation prématurée : La plupart du temps, les hébergeurs dimensionnent le nombre de connexions simultanées de manière à satisfaire tout le monde, tu n'as donc pas besoin de couper manuellement la connexion dans tes scripts de manière à gagner quelques pouillèmes de microseconde...
Si tu atteins le seuil de connexions simultanées, ce n'est pas en coupant dès que possible la connexion que tu résoudras le problème, mais en optimisant les requêtes elles-mêmes : ne pas faire un SELECT * si tu veux simplement compter le nombre de lignes, etc.
Bref, dans aucun cas il ne me semble utile de fermer manuellement la connexion à la base. L'avantage de cette pratique est que cela te permet de relancer une requête à tout moment sans te poser de question.
Ok merci pour ces précisions très intéressantes..Citation:
Envoyé par Yogui
Donc en gros j'ouvre ma connexion en début de page, je fais mes requêtes là où j'en ai besoin et point barre , c'est bien ça ? :roll:
C'est sur si tu as un site qui accueillle 1 personne par jour la inutile de dimensionner .Citation:
Envoyé par Yogui
Au contraire si ton site a un certain succés , il est préférable de fermer les connexions.
Une personne qui consulte ton site et qui ne referme pas son navigateur maintien la connexion.
sans compter celles qui surfent , on peut arriver vite au nombre de connexions autorisées PAR UTILISATEUR ; 48 pour infomaniak Une vingtaine POUR OVH , il ne faut pas être très fute fute pour le comprendre , tout ça bien sur si le site a pas mal de visites.
D'ailleurs OVH propose de redimensionner ce nombre à la hausse moyennant finance , tiens curieux !! n'est-ce pas !!!!
De toutes les façons , dans les FAQ il est conseillé cette façon de faire.
Pour info , pour ne pas te prendre la tête , tu fais un include d'une page en entete de ton script ou la tu as ton connect de ta base.
et en bas de ta pas tu fais un close de ta connexion avec un include .
tu inclus ces scripts a chaque fois que tu commences un script et la en effet tu te poses pas de question.....
Oui j'utilise l'appel d'une fonction pour l'ouverture de la BD.
C'est vrai que la façon la plus optimale serait la fermeture explicite à la fin de l'execution d'un script , mais je ne pense pas que ça se ferme automatiquement malheureusement :/