a) grosso modo on tourne a 300 requetes / secondes avec des piques a 1200.
Normalement ca devrait passer à condition de ne pas réétablir une connexion à chaque requète. Valider avec les devs que les connexions restent ouvertes un moment et servent à plusieurs requètes. Ca pourrait même valoir le coup de passer sur du pooling un peu costaud (penser à augmenter la mémoire dans ce cas là genre 8GB)
b)On a de tout au niveau des requetes, de la toute simple et de la trés compliqué avec 10 jointures et des dizaines de conditions. par contre pas de procédures stoquées. Par contre les jointures font qu'aucune division des tables pour les répartir sur plusieurs serveurs n'est visible.
Sur les requètes complexes on y gagne souvent à faire des vues, voire des vues stoquées mise à jour à intervalle régulier. Mais bon les vues stoquées et MySQL ca fait pas bon ménage.
c) en moyenne une centaine.
Là on a un problème : ca n'est pas normal que 100 utilisateurs fassent 300 connexions/seconde en soutenu. Il y a des mises à jour en continue (genre raffraichissement des données toutes les 5 secondes) ? Parceque sinon il y a un truc à creuser là. Je pense qu'une bonne partie de la logique de traitements/de filtres a du se retrouver dans les applis plutôt que sur le serveur. Si ca peut limiter le nombre de requètes ou la taille des données renvoyées il vaut mieux passer par des procédures stoquées.
e) on a environ 200 tables qui sont quasiment en permanence toute utilisée.
Ca par contre c'est largement en dessous de ce que MySQL peut faire. Une fois de plus un boost de mémoire devrait aider. Et comme les tables doivent être assez volumineuses il peut être bon de passer sur un RAID 10 (en gardant du SCSI/SAS, le Sata en accès concurrents c'est pas çà )
Pour postgreSQL a vrai dire on utilise mysql depuis trop longtemps pour pouvoir changer de base de donnée comme ca.
Il ne devrait pas y avoir de gros problèmes à faire la migration, surtout si il n'y a pas de procédures stoquées. Par contre après tu auras beaucoup plus de flexibilité pour répartir la charge, analyser les goulots d'étranglement etc.
Bref vu ta situation pas de solution miracle. Je pense qu'il y a un peu de ménage à faire au niveau du code car le nombre de requètes me parait disproportionné vu le nombre d'utilisateurs...
[^] # Re: On va essayer de répondre....
Posté par Jerome Herman . En réponse au journal Performance MYSQL. Évalué à 6.
Normalement ca devrait passer à condition de ne pas réétablir une connexion à chaque requète. Valider avec les devs que les connexions restent ouvertes un moment et servent à plusieurs requètes. Ca pourrait même valoir le coup de passer sur du pooling un peu costaud (penser à augmenter la mémoire dans ce cas là genre 8GB)
b)On a de tout au niveau des requetes, de la toute simple et de la trés compliqué avec 10 jointures et des dizaines de conditions. par contre pas de procédures stoquées. Par contre les jointures font qu'aucune division des tables pour les répartir sur plusieurs serveurs n'est visible.
Sur les requètes complexes on y gagne souvent à faire des vues, voire des vues stoquées mise à jour à intervalle régulier. Mais bon les vues stoquées et MySQL ca fait pas bon ménage.
c) en moyenne une centaine.
Là on a un problème : ca n'est pas normal que 100 utilisateurs fassent 300 connexions/seconde en soutenu. Il y a des mises à jour en continue (genre raffraichissement des données toutes les 5 secondes) ? Parceque sinon il y a un truc à creuser là. Je pense qu'une bonne partie de la logique de traitements/de filtres a du se retrouver dans les applis plutôt que sur le serveur. Si ca peut limiter le nombre de requètes ou la taille des données renvoyées il vaut mieux passer par des procédures stoquées.
e) on a environ 200 tables qui sont quasiment en permanence toute utilisée.
Ca par contre c'est largement en dessous de ce que MySQL peut faire. Une fois de plus un boost de mémoire devrait aider. Et comme les tables doivent être assez volumineuses il peut être bon de passer sur un RAID 10 (en gardant du SCSI/SAS, le Sata en accès concurrents c'est pas çà )
Pour postgreSQL a vrai dire on utilise mysql depuis trop longtemps pour pouvoir changer de base de donnée comme ca.
Il ne devrait pas y avoir de gros problèmes à faire la migration, surtout si il n'y a pas de procédures stoquées. Par contre après tu auras beaucoup plus de flexibilité pour répartir la charge, analyser les goulots d'étranglement etc.
Bref vu ta situation pas de solution miracle. Je pense qu'il y a un peu de ménage à faire au niveau du code car le nombre de requètes me parait disproportionné vu le nombre d'utilisateurs...