Nombre de connexions Mysql

[herve01]

Bonsoir,

Je m'intéresse de plus en plus aux offres en mutualisé d'OVH. Mais je constate qu'ils n'autorisent que 3 connexions sql simultanées. Je voudrais savoir si c'est un peu juste pour un site avec environ 500 visiteurs / jours ou ci ça passe à l'aise (je précise que tous mes scripts sont optimisée : connexions ouvertes au + tard et fermées au + tôt et que je suis loin d'un PhpNuke).

Hervé

[Haq]

Tu peux prendre un 60gp sans souci... pour à peine 15 euros par an (mon site y était sans problème avec 1000 à 1200 visiteurs uniques par jour).

Si tu ne le fais pas déjà, je te conseille d'alléger un peu mysql en utilisant du cache.

aK.

[Dr DLP]

Les connexions simultanées sont rarissimes avec des scripts faits correctement ( même sur phpnuke ) .
Ceci représente un accès à la base de données par deux utilisateurs au même moment , en sachant que la plupart des requêtes s'éxécutent en moins d'une milliseconde .

Moralité : statistiquement c'est très très largement suffisant !

[yanhl]

ca commence à être chiant à partir de 3000 visiteurs/jours si tu as de grosses tables et quelques jointures.
Dans mon cas, j'ai du splitter en 2 bases pour limiter les cas de triple connexion simultanée. Ceci dit, c'est rare que ça arrive, mais ça arrive quand même occasionnellement.
Du coup, ça m'a souvent freiné dans mes ambitions : j'évite toute requête un peu lourde, et même toute requête tout court en déportant dans des tableau PHP ce qui aurait plutôt sa place en base.

Et du coup je passe sur un dédié dans pas longtemps

[herve01]

Merci pour vos réponses.

Je fais tout pour réduire le nombre de requêtes. Mais pour cela on est parfois obligé d'utiliser des jointures qui permettent de faire 1 seule requête au lieu de 2 ou +.

A partir de quand une requête est-elle considérée comme lourde ? Quand on fait un SELECT * FROM sur une table avec plusieurs milliers denregistrements ?

@+
Hervé

[Dr DLP]

Oui , si tu obtient un résultat de plus de 10.000 entrées , tu peux considérer que la requête est lourde

Essaye d'éviter les SELECT * surtout , notamment si tu n'as besoin que d'un champ dans la table .
N'boulie pas non plus de vider les résultats en mémoire quand tu n'en as plus besoin .

[WebRankInfo]

j'ai entendu qu'il était inutile de fermer la connexion ou de libérer la mémoire car c'était fait automatiquement à la fin des scripts PHP. Qu'en pensez-vous ?

par ailleurs les connexions permanentes sont-elles intéressantes point de vue perfo ?

[Eservice]

Bonsoir,

A partir de quand une requête est-elle considérée comme lourde ? Quand on fait un SELECT * FROM sur une table avec plusieurs milliers denregistrements ?

Tu peux remplacer le 'select *' par un 'select champ1, champ2 ....' (sauf s'il te les faut tous) parce que ça bouffe du temps.
Ensuite il faut savoir si un index est utile pour ta requête et s'il sera utilisé vraiment.

j'ai entendu qu'il était inutile de fermer la connexion ou de libérer la mémoire car c'était fait automatiquement à la fin des scripts PHP. Qu'en pensez-vous ?

non, tu libéreras toujours des ressources plus tôt, surtout avec un traffic conséquent.

[WebRankInfo]

j'ai entendu qu'il était inutile de fermer la connexion ou de libérer la mémoire car c'était fait automatiquement à la fin des scripts PHP. Qu'en pensez-vous ?

non, tu libéreras toujours des ressources plus tôt, surtout avec un traffic conséquent.

tu l'as vérifié ou mesuré ?

[Eservice]

Je n'ai pas besoin de le mesurer. Si le serveur php ferme les ressources à la fin d'un script c'est parce qu'il a une table de pointeurs ouverts sur les ressources ouvertes, qu'il parcourt pour les fermer les unes après les autres en fonction de leur type. Il est probable que chaque ressource fait référence à une structure différente selon sa nature (fichier, table ...). D'autant plus si c'est une table de base de données qui va consommer encore plus de ressources sur le serveur en question. La laisser ouverte jusqu'au dernier moment monoplise des ressources systèmes (au niveau de l'OS entre autres) inutilement.
Plus ton site est sollicité et plus les ressources mémoire et disque le seront.

Il me semble que la règle d'or est "on ouvre le moins possible et on ferme dès que possible". Les problèmes de bande passante et de hits ne sont pas forcément les plus critiques pour un hébergeur : les ressources mémoires et de connexion externe (socket) et interne (serveur applicatif et de base de données) posent souvent plus de problèmes.

[WebRankInfo]

sauf si ouvrir et fermer une connexion MySQL prend un temps non négligeable ?

[Eservice]

De toutes manières libérer une ressource prend du temps alors pourquoi la laisser ouverte pour rien ? surtout si sa libération laisse la place à un autre visiteur

[mahefarivony]

je serai vraiment curieux de voir le benchmarking d'un serveur mysql.. ca doit etre rigolo a voir..

[Eservice]

WRI tu faisais allusion aux connexions persistantes ? Je n'ai pas mesuré mais ça m'étonnerait beaucoup que ça te fasse gagner un temps significatif, surtout s'il est sur la même bécane.
En plus ça peut poser un problème de mémoire : tu vas monopoliser des buffers de connexions en permanence comme si tu étais en période de charge tout le temps. Est-ce gênant dans ton cas ?

Si tu veux gagner du temps c'est les structures des tables et des index qu'il faut revoir (et les paramètres du serveur) . C'est facile à dire ...

[herve01]

La meilleure façon d'accélérer un site est d'optimiser les scripts et schémas de tables sql de manière à ce qu'ils consomment le moins de ressources possibles.
Ainsi Mysql sera moins sollicité, et les requêtes s'effectueront plus rapidement.

Sans oublier d'utiliser mysql_free_result(), mais uniquement à bon escient.

Hervé