Nombre de connexions SQL chez OVH espagne limitées!

[klendrier]

Le liens ci contre fournit les données techniques des pack chez OVH en Espagne: http://www.ovh.com/fr/produits/mutualise.xml
Ce qui est bizare c'est qu'ils limitent le nombre de connexions à la base SQL!!! Ce qui est encore plus bizare c'est que meme les superpack de pro sont limités a 50.. c'est possible selon vous ou il y a qqc que ne comprends pas?
Merci pour votre aide.
Vins.

 

[Ohax]

dit toi que dans la vie rien n'est illimité sauf la finalité des choses ;-)

 

[klendrier]

Comprends pas ..tu peux pas être plus clair?

Comprends pas ..tu peux pas être plus clair?

 

[Ohax]

Rien n'est illimité ;-)

 

[zimounet]

Ohax, si c'est pour dire des trucs philosophiques qui ne veulent rien dire, c'est pas la peine de répondre!

Dit toi qu'en informatique, et dans le domaine des nouvelles technologies, il faut etre cartésien, et pas avoir de propos philosophiques volatiles, et inutiles!

Bref, pour te répondre, 50 requetes, c'est le nombre de requete autorisé simulanément dans une milliseconde.

zim en directe d'annecy, et a montpellier par tel avec mlamoto

 

[louloulou]

Bref, pour te répondre, 50 requetes, c'est le nombre de requete autorisé simulanément dans une milliseconde.

ben dans ce cas ça laisse beaucoup de marge alors, parce que avoir 50 visiteurs/requettes par milliseconde à la fin du mois ça doit faire beaucoup beaucoup de VU non?

 

[spidetra]

Le liens ci contre fournit les données techniques des pack chez OVH en Espagne: http://www.ovh.com/fr/produits/mutualise.xml

OVH espagne ça existe ?
Le site est bien traduit en espagnol, mais tu es sur que les serveurs sont hébergés en Espagne ? Ils ne seraient pas plutot bien au chaud a Paris ?

 

[Ohax]

Tu me fait la gueule ou quoi mon zimounet ? ;-)

Je t'appel ce soir ? ^^

 

[petit-ourson]

Ohax, si c'est pour dire des trucs philosophiques qui ne veulent rien dire, c'est pas la peine de répondre!

Dit toi qu'en informatique, et dans le domaine des nouvelles technologies, il faut etre cartésien, et pas avoir de propos philosophiques volatiles, et inutiles!

Bref, pour te répondre, 50 requetes, c'est le nombre de requete autorisé simulanément dans une milliseconde.

zim en directe d'annecy, et a montpellier par tel avec mlamoto

J'ai un peu délirer là [edit]

 

[zimounet]

non 50 c'est le nombre de requete qui peut etre executé en une milliseconde au total sur l'hébergement!

Exemple, tu as une page, avec 2 requetes, 25 visiteurs execute simultanément cette page (ce qui est impossible dans la pratique), il y a de forte chance pour que sa dépasse le cota!

Mais en pratique, c'est pas sur 25 visiteurs que tu vas y percevoir des limittes, meme a 5 requetes par page, car une requete "normal" est executé en moins d'une poigné de milliseconde (je ne saurais dire combien mais TRES peu)

C'est quand tu joue sur le nombre élevé de visiteurs, qui execute des applications comportant de nombreuses requetes (forum etc)...

Tu verra alors apparaitre un message du genre "too many connexions"

Bref petit ourson, au lieux de "contre-exempler" de manière débile et completement disproportionné (1+1=2/4!=12.9 donc tu as tord petit ourson), renseigne toi!

Ohax, je suis tout fievreux, la je vais me coucher, et exceptionnelement pour cette semaine, je vais dormis plus d'une heure

 

[e-kiwi]

50 ? c est immense comme limite ! en mutualisé classique, ca tourne plutot dans les 5-7. et un site bien optimisé peut accueiilr des centaines de milliers de visites / mois avec cette limite, alors 50... tu aura jamais de too many connexions

 

[zimounet]

Même si ma requête SQL dure 30 secondes ce qui voudrait dire que je peux avoir : 29 * 1000 * 50 = 1 450 000 connections à la 29e secondes

Non si ta requete du 30 seconde, a la trentieme seconde ta requete sera juste terminé! Et si tu as juste une requete d'executé de trente seconde sur le serveur, sa fera 1 connexion par milliseconde comptabilisé pendant 30 seconde, donc tu peux mettre 50 visiteurs qui execute simultanément cette requete, et la tu en verra en effet la limite, le 51eme a executer la requete verra un message "too many connexion etc"

Mais vue qu'une requete a mysql ne prend qu'un temps minimum (quelques milliseconde/requete, a part pour les requete de barjos)....

Genre dans une page tu as 5 requetes de 3 millisecondes chacunes, entre chacune de celles ci tu as 5 millisecondes (temps de génération php), donc si on imagine que ces chiffres sont proportionnel (pas représentatif biensur), on peut dire que 50 req max, c'est énorme! mais je m'évade la, je ne maitrise plus assez la chose pour rentrer dans le détail avec justesse.

 

[zimounet]

50 ? c est immense comme limite ! en mutualisé classique, ca tourne plutot dans les 5-7. et un site bien optimisé peut accueiilr des centaines de milliers de visites / mois avec cette limite, alors 50... tu aura jamais de too many connexions

Le deuxieme pack celeonet est a 20 requetes / milliseconde! Et j'ai eu un site qui tournais la dessus en moyenne trois requetes par page (ce qui est peu) et je tournais dans les 50 connecté simultanée, et je n'était pas pres de voir des limittes de ce coté ci!

Bref, avec 50 req, c'est énormissime!

 

[petit-ourson]

Chez ovh ce sont des requetes simultanée et non par miliseconde.

* vous ne fermez pas les connexions vers le serveur MySQL. MySQL doit attendre le timeout pour libérer une connexion.La solutions consiste à mettre dans le code les fermeture de la connexion.


* la connexion vers MySQL prend trop de temps. C'est souvent dû au fait que vous ouvrez la connexion vers MySQL au débutd'une page, au milieu de la page vous mettez les commande (select, update), puis à la fin une fermeture. Ceci fonctionne, mais
si le visiteur de votre site a une mauvaise connexion, il mettra du temps à charger la page et ne libera pas de connexion MySQL rapidement.
La solution consiste à ouvrir une connexion vers le serveur MySQL seulement si vous avez besoins et au moment où vous en avez besoins,
faire les opérations nécessaire et fermer de suite la connexion. Vous pouvez utiliser des variables pour stocker les données après un accès
à la base. Plus le temps d'une connexion est courte, plus vous pouvez faire des requêtes par seconde sur le serveur MySQL.

Donc comme vu on ne parle pas de miliseconde, mais bien une connexion sur la base de données (même sans requête à vrai dire.

PS : ouaip mon calcul était délirant lol mais on reste à dire qu si ma requete dure 30s (ou plutot ma connexion avec x requetes possibles), alors je pourrai avoir 50 connexions dans ce laps de temps maximum.

Si la connexion dur 10 fois moins longtemps, je pourai avoir 10 fois plus de connexions maximum, etc etc

 

[zimounet]

Chez ovh ce sont des requetes simultanée et non par miliseconde.

* vous ne fermez pas les connexions vers le serveur MySQL. MySQL doit attendre le timeout pour libérer une connexion.La solutions consiste à mettre dans le code les fermeture de la connexion.


* la connexion vers MySQL prend trop de temps. C'est souvent dû au fait que vous ouvrez la connexion vers MySQL au débutd'une page, au milieu de la page vous mettez les commande (select, update), puis à la fin une fermeture. Ceci fonctionne, mais
si le visiteur de votre site a une mauvaise connexion, il mettra du temps à charger la page et ne libera pas de connexion MySQL rapidement.
La solution consiste à ouvrir une connexion vers le serveur MySQL seulement si vous avez besoins et au moment où vous en avez besoins,
faire les opérations nécessaire et fermer de suite la connexion. Vous pouvez utiliser des variables pour stocker les données après un accès
à la base. Plus le temps d'une connexion est courte, plus vous pouvez faire des requêtes par seconde sur le serveur MySQL.

Donc comme vu on ne parle pas de miliseconde, mais bien une connexion sur la base de données (même sans requête à vrai dire.

PS : ouaip mon calcul était délirant lol mais on reste à dire qu si ma requete dure 30s (ou plutot ma connexion avec x requetes possibles), alors je pourrai avoir 50 connexions dans ce laps de temps maximum.

Si la connexion dur 10 fois moins longtemps, je pourai avoir 10 fois plus de connexions maximum, etc etc

Peut etre que je me trompe, mais cela reviens quasiment DPAM (du pareil au meme) car une page en général se génère en moins d'une ou deux secondes!

Et ils dise sur le site de ovh que si le visiteurs a une connexion de merde, la page sera plus longtemps connecté a mysql, enfin la connexion a mysql sera plus longues, mais c'est pas le visiteurs qui se connecte a mysql que je sache? C'est le visiteurs qui lance la génération de la page par php et php qui va demander a mysql les infos... Bref, moi j'crois qu'ils ne se sont pas foulé!

Quoiqu'il en soit 50 connexion simultanée, a moins que tu as + de 100 personnes simultanée sur un CMS, un forum ou un wiki, tu as de la marge!

 

[petit-ourson]

Peut etre que je me trompe, mais cela reviens quasiment DPAM (du pareil au meme) car une page en général se génère en moins d'une ou deux secondes!

La même chose si la conexion à la base + les requetes + la fermeture font moins de 1 milliseconde, si ca prend 1 seconde, ce n'est plus la même chose (c'est 1000 fois moins bien même).

En gros ce que conseille ovh c'est de na pas faire un truc du style

<?php ouverture de ma connexion à la base ?>
<html>
....
<body>..... etc .... <?php Requete(s) SQL ?> ..... etc <?php un autre script ?> ....</body></html>
<?php Fermeture de la connexion à la base ?>

Si ton autre script dure 1 seconde, tu vas augmenter ton nombre de connexion simultanée à la base alors que si tu fais un truc qui ressemble à cela :

<?php ouverture de ma connexion à la base ?>
<?php Requete(s) SQL ?>
<?php Fermeture de la connexion à la base ?>
<html>
....
<body>..... etc ....  ..... etc <?php un autre script ?> ....</body></html>

Meme avec un script qui dure 1s, tu auras moins de connexion simultanée sur ta base.

En gros, il faut eviter de laisser les connexion ouvertes sur mysql si on en a pas besoin.

PS: Je pense pas que OVH ne ce soit pas foulé, ils ont juste expliqué le principe ... Pourquoi la plupart des forums, des cms, utilise la prog objet pour mettre les infos recupéré en base ?? Ca leur permet de recuperer les infos se trouvant en base de données dans un premier temps (1) (connexion + recuperation + deconnexion), dans un second temps ils s'occuppent de l'affichage qui la peut être plus ou moins long en fonction des traitements a faire côté serveur (donc identique pour tout le monde) (2) + de l'envoie des données au navigateur qui là dépend du client (3).

Si la partie (1) dure 0.5 seconde, la partie (2) dure 1 seconde et la (3) variable suivant le client dure 5s, tu n'auras monopolisé ta base de données que 0.5s (cas 2 conseillé), et 6.5s si tu ferme ta connexion qu'a la fin de ton script/page (cas 1 déconseillé).