Combien de sélections par seconde un serveur mysql peut-il exécuter?
J'écris un plan d'affaires et je dois simuler le coût lorsque mon site Web atteindra 500 000 visiteurs uniques.
- visiteurs: 500.000
- pages vues: 1 500 000
- pages vues d'araignée: 500 000
- nombre total de pages vues: 2 000 000
Chaque page fait 50 requêtes + -
- requêtes par jour: 100 millions
- par heure: 4 millions
- par minute: 70 000
- par seconde: 1,200
- pic: 3000
Pour faire ce calcul, j'ai besoin de 3 000 requêtes par seconde ... quel type de serveur peut le gérer?
Le problème est: en fait, mon site fait 2 000 visites par jour, et ayant - + 150/200 requêtes/seconde ... à partir de ce point, je m'attends à 50 000 requêtes/seconde.
Combien de serveurs dont j'ai besoin dans le cluster ou la réplication gèrent ce travail?
Je travaillais pour une entreprise de commerce électronique avec un site Web qui affichait plusieurs millions de pages consultées par jour. Nous avions un seul Dell PE 1750 avec 2 processeurs monocœur et 2 Go de RAM, taille de la base de données env. 4 GO. Aux heures de pointe, ce serveur a traité jusqu'à 50 000 requêtes et plus par seconde.
Cela dit: la base de données était bien structurée, toutes les requêtes étaient affinées (nous avions des sessions hebdomadaires analysant les journaux de requêtes lentes et réparant les requêtes et les index) et la configuration du serveur était également affinée. La mise en cache est certainement une bonne idée, mais MySQL le fait de toute façon, il vous suffit d'analyser les performances et d'affiner la façon dont votre mémoire est utilisée (cache de requête vs autres options).
D'après cette expérience, je peux vous dire que l'impact le plus élevé est causé par des index manquants, des index incorrects et une mauvaise conception de la base de données (par exemple, de longs champs de chaîne comme clés primaires et des non-sens similaires).
Tout dépend de la complexité de la requête, de la quantité de mémoire des serveurs et de la vitesse des disques.
Si les requêtes sont très simples ou très bien réglées, un seul grand serveur de base de données peut gérer cela. Si toutefois les requêtes sont très complexes (ou simples mais mal réglées), vous aurez besoin de plusieurs serveurs.
Cela ne peut vraiment pas être estimé sans rien savoir des requêtes spécifiques que vous exécutez, du schéma de base de données et de sa taille.
Un simple SELECT sur une colonne indexée est assez une bête différente de quelques JOIN basés sur des non indexés .. et bien sûr les choses changent beaucoup si les tables impliquées contiennent 1K enregistrements ou 1M.
Aussi:
- Quelle est votre configuration matérielle actuelle?
- Quelle part de sa puissance (CPU, RAM, E/S disque) votre serveur utilise-t-il sous la charge actuelle?
Comme l'a fait remarquer Ignacio, vous voudrez peut-être examiner la mise en cache. Dans les cm ou peut-être même devant la pile. Plus de 50 requêtes pour chaque (chaque!) Page, c'est vraiment beaucoup.
Pour les grands ensembles de données "chauds", cela vaut probablement l'investissement en temps pour se convertir à un schéma "big data", c'est à cela qu'ils servent. Par exemple, si vous avez une grande quantité de données à récupérer, mais que vous ne réécrivez jamais, mais seulement ajoutez de nouvelles données, regardez Apache Hive. Naviguez autour, c'est généralement une saveur que vous pouvez interfacer assez facilement avec le code existant, qui empêchera également les brûlures d'estomac de manquer d'espace de cache.
Il y a trop de choses qui peuvent affecter vos requêtes par seconde, veuillez ne pas faire confiance à mes données sans vous tester. Je poste mon résultat de test de vitesse ici pour aider quelqu'un à estimer le qps avec la base de données et la machine mysql (2018-09) actuelles. Dans mon test, le la taille des données est inférieure à la mémoire du serveur (qui réduit considérablement IO et améliore beaucoup les performances).
J'utilise une mémoire d'un processeur de 3,75 Go, 100 Go de SSD, une instance de serveur gcp cloud mysql et j'obtiens:
- 1 client, un sql une ligne lu: 799 sql/seconde.
- 50 clients, un sql une ligne lu: 6403 sql/second.
- 50 clients, une écriture sql une ligne: 4341 lignes écrites, qps. 4341 m²/seconde.
- 1 client, 30 000 lignes d'écriture par sql: 92109 lignes/s écrites.
À en juger par vos commentaires, le plus grand facteur sera la taille de votre ensemble de données, ou au moins la taille de l'ensemble de données "à chaud". 3000 qps ou même 8 000 qps sur un serveur 16 cœurs ne sont pas du tout un problème tant que le serveur doit rarement aller sur le disque pour satisfaire la requête. Une fois que l'ensemble de données actif dépasse la quantité de mémoire qu'InnoDB utilise pour le mettre en cache, vos performances chutent rapidement.