Besoin d'un conseil en hébergement

[bidulemachin]

Bonjour à tous,

Je me doute que le sujet a du déjà etre évoqué mais vu la particularité mon cas, je préfère poster directement un nouveau message.
Donc voila ma situation : Je suis client chez OVH, une petite offre start, la plus simple pour commencer mon site, seulement après 5 mois, mon site est victime de sa popularité et m'affiche souvent le charmant message "max users connection" bref, j'aimerai bien y remédier car c'est mon seul problème pour le moment, j'ai pas besoin d'une base de données super énorme, ou d'un espace disque surdimensionné

Donc voila quel type d'hébergement me conseillez vous pour être tranquille au niveau des connec simultanées?

PS : Mon code est totalement clean, chaque connexion à la base est en suite refermée juste après

 

[polweb]

Ben tu peux passer au 60 gp pour pas cher. Ensuite faut voir ton nombre de connections simultannées, sinon il y a le 90 plan.

 

[bidulemachin]

Pour l'instant j'en suis à 200 - 300 et j'aimerai viser un peu plus haut quand même mais bon je sais pas trop quoi choisir au niveau qualité / prix pour ce qui correspond à ce que je recherche

 

[Bool]

Donc voila quel type d'hébergement me conseillez vous pour être tranquille au niveau des connec simultanées?

un VDS ou RPS... au moins MySQL n'aura pas de bridage sur le nombre de connexions simultanées.

Toutefois s'il s'agit d'un script maison, il suffirait de quelques modifications pour éviter ça :
- établir la connexion seulement si nécessaire, et la fermer dès que possible
- utilisation de cache (de données, d'affichage, voir même HTTP)
- optimisation des traitements SQL (revoir les requêtes, index, etc)

 

[bidulemachin]

Donc voila quel type d'hébergement me conseillez vous pour être tranquille au niveau des connec simultanées?

un VDS ou RPS... au moins MySQL n'aura pas de bridage sur le nombre de connexions simultanées.

Toutefois s'il s'agit d'un script maison, il suffirait de quelques modifications pour éviter ça :
- établir la connexion seulement si nécessaire, et la fermer dès que possible
- utilisation de cache (de données, d'affichage, voir même HTTP)
- optimisation des traitements SQL (revoir les requêtes, index, etc)

Pour ce qui est de l'optimisation, à part le cache, tout est OK

J'ai vu que le 90 plan proposait 10 connec simultanées, ca serait pas suffisant ? Sachant que ya pas plus de 10 connec à la base par page

 

[techron]

Pour l'instant j'en suis à 200 - 300 et j'aimerai viser un peu plus haut quand même mais bon je sais pas trop quoi choisir au niveau qualité / prix pour ce qui correspond à ce que je recherche

200 à 300 connexions a MySQL au même moment OU 200 à 300 connectés en ligne ?

 

[bidulemachin]

200 à 300 connexions a MySQL au même moment OU 200 à 300 connectés en ligne ?

200 à 300 connectés ! Avec l'offre d'OVH que j'ai aujourd'hui je n'ai pas droit aux connecs simultanées

 

[techron]

Pour ce qui est de l'optimisation, à part le cache, tout est OK

J'ai vu que le 90 plan proposait 10 connec simultanées, ca serait pas suffisant ? Sachant que ya pas plus de 10 connec à la base par page

Cela pourrait suffire un certain temps.

Le mieux serait que vous trouviez un hébergeur mutualisé qui autorise une limite plus élevée du nombre de connexions MySQL simultanées. Cela peut aller jusquà 50-75 maximum. D'autres hébergeurs n'imposent pas de limites sur le nombre maximum de connexions MySQL mais limitent sur d'autres points: les ressources CPU, le nombre de connectés (50 connectés maximum aux 15 minutes par exemple), etc.

 

[techron]

200 à 300 connexions a MySQL au même moment OU 200 à 300 connectés en ligne ?

200 à 300 connectés ! Avec l'offre d'OVH que j'ai aujourd'hui je n'ai pas droit aux connecs simultanées

200 à 300 connectés aux 15 minutes ?

 

[Bool]

plus de 10 connec à la base par page

rassures moi, tu veux dire 10 requetes par page, pas 10 connexions ?




PS : en même temps 10 connexions simultanées à MySQL, c'est déjà beaucoup pour un seul site Web je trouve. Même mes clients à fort trafic (cluster...) n'atteignent ce seuil qu'en cas de problème.

 

[bidulemachin]

Bah une requête = une connec pour garder la connexion le moins longtemps possible.

En tout cas merci pour vos conseils, mais pensez vous que je doive changer d'hébergeur ? Parce qu'OVH ils sont plutot pas mals et supposé que ca tient le coup avec 200/300 visiteurs aujourd'hui, avec 10 connecs simultanées je peux au moins visiter 10 fois plus non ?

 

[techron]

PS : en même temps 10 connexions simultanées à MySQL, c'est déjà beaucoup pour un seul site Web je trouve. Même mes clients à fort trafic (cluster...) n'atteignent ce seuil qu'en cas de problème.

Il y a quelques années, Google affichait pas mal de clients OVH avec le message d'erreurs qu'obtient bidulemachin. J'ai pas mal parcouru ces sites. Ils avaient en moyenne un maximum de 20 connectés en ligne sur un base avec 3 connexions MySQL simultanées. Avec 10 au lieu de 3, c'est un peu plus, disons 50-75 pour un script de forum genre phpBB sans obtenir le fameux message d'erreurs.

200 à 300 connectés aux 15 minutes, c'est beaucoup en mutualisé. Tout dépends des limites sur l'hébergement écrites dans les conditions générales de ventes.

 

[Bool]

Bah une requête = une connec pour garder la connexion le moins longtemps possible.

Beurk. Là ton site passe son temps à se deco/reco, je ne suis vraiment pas certain que ce soit mieux.

Pour moi c'est plutôt établissement de la connexion uniquement à la première requête, exécution de tous les traitements, fermeture de la connexion dès qu'on en a plus besoin, puis génération de l'affichage et autres traitements ne nécessitant pas de connexion.

Sinon comme je disais, j'ai des clients qui font plus de 2000 requêtes SQL par seconde en heure de pointe et qui ne dépassent pas les 10 connexions simultanées. Ils ne sont pas non plus en mutualisé, mais je ne peux m'empêcher de penser que le problème se situe de ton coté.
Trop de requêtes ayant recours au disque et/ou des problèmes de verrous dans ces requêtes : la cause de ces deux problèmes peut parfois être la même, c'est à dire des requêtes faisant un usage intensif de table temporaires et/ou filesort.

Quand tu dis avoir optimisé les traitements SQL, tu as vérifié les EXPLAIN de toutes tes requêtes ?

 

[Bool]

esf : effectivement, perso le seul serveur qui fait du mutualisé et que je gère limite à 5 connexions simultanées, et les erreurs sont assez rares. Donc à moins que les serveurs MySQL d'OVH soient bourrés à raz bord, je reste étonné qu'un tel trafic puisse provoquer des problèmes.

Après effectivement s'il s'agit d'un phpBB 2 ou autre script mal foutu, c'est une autre histoire.

 

[bidulemachin]

Non mais c'est tout à fait possible que j'ai mal codé mon site, je demande qu'à apprendre.
Avant je fesais le truc assez barbare qui consistait à me connecter une fois et à me déconnecter qu'une fois la fin de page, bref j'ai vu qu'il fallait garder une connexion ouverte le moins de temps possible, c est pour ca que j'ai adopté cette méthode mais je l'ai peut etre comprise de travers.

Tu me conseilles donc d'avoir une seule connexion par page, de faire tous mes traitements et de répartir ensuite les résultats sur ma page ?

 

[Bool]

C'est en tous cas ce que je fais oui. Après je ne connais pas ton code, tu as peut être un contexte spécifique.
Typiquement je m'arrange généralement pour couper toute connexion MySQL et fermer la session (si ouverte) avant le moindre affichage.


Mais as tu la possibilité d'auditer tes requêtes ? (faire un explain après chacune d'elle, tracer toutes les requêtes qui mettent plus de XXX ms à s'exécuter, etc)

 

[bidulemachin]

Désolé je dois sembler un peu lourd :roll:

Comment tu t'y prend exactement pour traiter l'affichage ensuite ? Un max de variables ? Des tableaux sur lesquels tu boucles ensuite ? Ou une variable qui contient le code html résultat ?

 

[Bool]

Des tableaux contenant uniquement les données nécessaires.

Coté "perfs" tout est souvent histoire de compromis : je consomme un peu plus de mémoire, mais en contrepartie je peux libérer les ressources posant problème le plus tôt possible (et en passant le découpage par objet/méthode/fonction facilite grandement la mise en cache partielle).

 

[bidulemachin]

Donc selon toi, une seule "grosse" connexion vaut mieux que dix petites ? De cette façon, avec 5 connec simultanées mon serveur pourra supporter à peu près combien de visiteurs simultanées?

 

[Bool]

Je pense que c'est préférable oui, dès lors qu'il n'y ai pas non plus de traitement "bloquant" entre les requêtes SQL.

Pour ce qui est de l'estimation en visiteurs simultanées, j'en serais bien incapable. C'est complètement dépendant de ton code, de tes requêtes, de ta base, de ta façon de compter les "visiteurs simultanées", et de la charge actuelle du serveur.

Des clients dépassent largement les 100'000 VU par jour sans dépasser ces 5 connexions simultanées... et actuellement tu les satures avec je pense beaucoup moins de trafic... comme quoi...

 

[bidulemachin]

Je te remercie bien de ta réponse, et de toutes les autres aussi d'ailleurs.

Dernière petite question, aurait tu une page expliquant un petit peu ta technique d'une connexion par page ? Ca peut toujours aider d'avoir un exemple

 

[Bool]

Désolé mais je ne connais pas de "tuto" pour ce genre de chose.
Ce n'est en soit pas compliqué : tu établis la connexion que quand tu en as besoin, et tu la détruits quand ce n'est plus le cas. Qu'est ce qui te bloque ici ?

Au pire tu peux toujours utiliser PDO, le destructeur sera appelé dès que tu n'utiliseras plus l'instance.

 

[bidulemachin]

C'était pour avoir un exemple sur lequel s'appuyer, pour éviter de me tromper et d'avoir une page encore plus gourmande qu'elle ne l'est déja !

 

[hebmaster]

200-300 visiteurs en ligne, ça fait plus de 30000 visites/j...tu dois avoir un serveur dédié dans ce cas.

Avec autant de visiteurs, payer 20€/mois pour un serveur ne vas pas te faire ruiner...

 

[Leonick]

200-300 visiteurs en ligne, ça fait plus de 30000 visites/j...tu dois avoir un serveur dédié dans ce cas.

Avec autant de visiteurs, payer 20€/mois pour un serveur ne vas pas te faire ruiner...

je pense qu'il doit s'agir du nombre de visiteurs en pointe. Et peu de sites ont un lissage de leur courbe sur la journée (semaine - mois)