[SeriousJ]

Tu as quoi comme taille de table ?
J'ai constaté le même problème.

Ma théorie :
Sur le sql mutu tu peux profiter de plusieurs CPU alors que sur le privé tu as les ressources garanties mais tu as seulement un nbre de vcore limité donc les requetes sont faites en série plutôt qu'en parallèle lorsque c'est possible.
Donc sur une grosse table ou un SELECT prend par exemple 5 secondes avec 30 visiteurs simultanés (30 requêtes), les requetes s'empilent et ça rame sur sql privé alors que ça roule sur mutu.

Si OVH sort un SQL privé ou on peut sélectionner la RAM ET le nbre de vcore, ce serait top :-)

Ta réponse est peut-être la bonne mais on ne pourra pas en être sûr.

De mon côté, ce n'est pas la taille des tables qui est le problème. Même une requête sur une table d'une centaine d'enregistrements prend plus de temps sur SQL privé que sur SQL mutualisé.

J'ai contacté le support et on m'a répondu que les SQL mutualisés avaient des configurations optimisées. Pourtant j'ai bien optimisé la configuration de mon SQL privé. Comme tous ceux qui ont commandé un SQL privé ont le même problème, j'imagine qu'il ne s'agit pas d'un problème d'optimisation.

Ce qui est certain c'est qu'il faut fuir les SQL privés !!!

Pour ma part, j'aurais dû mieux lire les forums avant d'en commander un.

[jsys]

Tu as quoi comme taille de table ?
J'ai constaté le même problème.

Ma théorie :
Sur le sql mutu tu peux profiter de plusieurs CPU alors que sur le privé tu as les ressources garanties mais tu as seulement un nbre de vcore limité donc les requetes sont faites en série plutôt qu'en parallèle lorsque c'est possible.
Donc sur une grosse table ou un SELECT prend par exemple 5 secondes avec 30 visiteurs simultanés (30 requêtes), les requetes s'empilent et ça rame sur sql privé alors que ça roule sur mutu.

Si OVH sort un SQL privé ou on peut sélectionner la RAM ET le nbre de vcore, ce serait top :-)

[SeriousJ]

J'ai une offre Performance 4 pour un site qui tourne à environ 2 500 visites par jours.

Je commençais à arriver à la limite du nombre de connexions sur MySQL (30 connections simultanées max.) J'ai donc pris un SQL privé avec une RAM de 1 024.

Et là surprise : le SQL privé tourne beaucoup plus lentement que celui qui était mutualisé. Les requêtes prennent de 2 à 30 fois le temps qu'elles prenaient sur le mutualisé !

J'ai passé toute une journée à bidouiller le fichier de configuration my.cnf sans arriver à une amélioration notable. Dans mes recherches, j'ai constaté que de très nombreux utilisateurs ont rencontré le même problème.

Quelqu'un sait-il comment faire ? Y a-t-il une configuration optimale à respecter ? Le problème vient-il d'OVH ?