Commençons par la fin :
nous avons actuellement intel xeo 2.4ghz avec 4gb de ram.
C'est peut-être cela le coupable. 4gb de RAM, c'est une blague pour un quad core, surtout si l'on traite des milliers de requêtes en parallèle. 4096mb RAM par 2000 requêtes (définition inférieure de milliers) laisse 2mb RAM par requête (en ignorant tout le reste).
Vous n'avez certainement pas de problème avec MySQL SEULEMENT. Le problème principal est que vous avez besoin d'une infrastructure complète qui permette de traiter plusieurs milliers de requêtes par seconde (ou que quelqu'un clarifie votre message), ce qui signifie beaucoup de bande passante réseau, beaucoup de bande passante IO, et un serveur avec beaucoup plus de mémoire vive que - désolé - une station de travail bas de gamme bon marché et dépassée (c'est tout à fait ça - ma station de travail de développeur avait 4gb il y a environ 3 ans, et est récemment passée à 8gb). Vous aurez également besoin d'un sous-système d'E/S pour gérer la charge, ce qui signifie probablement de nombreux disques dans un bon contrôleur RAID matériel (oubliez les logiciels ici - vous voulez quelque chose avec plus de fonctionnalités que votre raid logiciel).
-
HTTP Load balancing : facilement réalisable, soit en logiciel, soit en matériel (F5 a du matériel pour cela). En fonction de votre programmation (sessions), vous pouvez avoir besoin de sessions collantes afin que le même client se retrouve à nouveau sur la même boîte.
-
La première étape consisterait à séparer les fichiers de téléchargement du site web actuel (domaine / sous-domaine séparé) et, dans le processus suivant, à les déplacer sur des serveurs séparés. La base de données MySQL (enfin, la base de données - ceci n'est en aucun cas spécifique à MySQL) peut également être placée sur un serveur séparé.
-
2000 requêtes par seconde ne nécessitent pas plusieurs serveurs, sauf si les requêtes sont complexes, ce qui n'est probablement pas le cas. La principale limitation de ces performances est très probablement le côté IO. Dans votre cas, je parie que vous couplez les 4 Go de RAM avec un sous-système de disque bas de gamme. Pour vous donner une idée de ce à quoi peut ressembler un serveur de base de données, ma propre base de données principale (qui stocke des données financières) dispose d'environ 10 disques à grande vitesse (Velociraptors, 10k RPM) pour s'assurer que la base de données (dans mon cas, un serveur SQL) ne devienne pas le goulot d'étranglement. J'ai encore des problèmes de performance du côté des entrées-sorties... je vais donc probablement déplacer certains éléments vers des disques SSD. Techniquement, à moins de ne faire que du reporting à partir de la mémoire (ce qui est très improbable avec votre configuration de 4 Go de RAM partagée pour tout), le sous-système IO est la principale limitation pour les bases de données.
En fin de compte, beaucoup de choses dépendent de votre programmation. Vous ne trouverez pas de réponse décente ici - cela demande beaucoup de planification et d'examen de votre code.
