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 :/