Combien de sélections par seconde un serveur mysql peut-il exécuter?

19

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 ce calcul, j'ai besoin de 3 000 requêtes par seconde ... quel type de serveur peut le gérer?

Le problème est le suivant: en réalité, mon site fait 2 000 visites par jour et a - + 150/200 requêtes / seconde ... à partir de ce moment, 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?

mysql linux

— Réintégrer Monica
source

5

Quel type de site 8k + interroge une visite?

— Ignacio Vazquez-Abrams

5

Vous avez besoin d'un examen de la conception du système immédiatement.

— Chopper3

1

Nulle part assez d'informations, car vous ne nous avez rien dit sur ce qui compte vraiment - les requêtes elles-mêmes. Vous n'avez pas non plus à nous parler de la machine que vous utilisez. Est-ce un 486? Le dernier et le plus grand super ordinateur ou quelque chose entre les deux? Tous ces chiffres que vous avez énumérés sont sans rapport avec la question. Veuillez fournir des informations PERTINENTES.

— John Gardeniers

> Quel type de site 8k + interroge une visite? je reçois 2000 visiteurs uniques mais chaque visiteur ouvre de nombreuses pages, + j'ai beaucoup d'araignées à l'intérieur. 2000 utilisateurs uniques génèrent 6000 ips uniques ouvrant plus de 120 000 pages ouvertes quotidiennement. merci

22

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 fixant 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).

— Wolfgangsz
source

8

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.

— mrdenny
source

Ou de sérieux changements de schéma et réindexation ...

— Massimo

3

Le réglage est TOUJOURS préféré à l'ajout de matériel supplémentaire. L'ajout de matériel masque simplement le problème jusqu'à ce que le problème soit beaucoup plus difficile à résoudre.

— mrdenny

Merci pour la réponse, donc je pense que 2 serveurs en parallèle + 1 passif pour la redondance devraient être ok, non? je parle de 2x serveurs quad core avec 32 g de ram et des disques rapides. ai-je raison? rappelez-vous que j'ai besoin de performances!

1

tout est bien réglé et indexé, j'ai 1 ou 2 requêtes lentes par semaine (et le temps de requête lent n'est que de 2 secondes) de toute façon j'écris un plan d'affaires, et j'aimerais savoir quel type de pool de serveurs peut gérer 12 000 000 de pages ouvertes générées quotidiennement avec 8 000 requêtes / seconde

8 000 requêtes par seconde, ce n'est pas tant que ça. Un seul serveur 16 cœurs fera probablement l'affaire. 64 Go de RAM (ou plus ou moins selon la taille de la base de données et la quantité de données qui doivent être conservées en cache à tout moment) devraient faire l'affaire. Ma base de données (octroyée pour son serveur SQL) est de 1 To sur un serveur 64 cœurs 64 Go de RAM avec 40 à 50 000 utilisateurs qui la frappent quotidiennement jusqu'à plusieurs fois par minute (chacun) tout au long de la journée.

— mrdenny

3

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 une bête très différente de quelques JOIN basés sur des colonnes non indexées ... 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?

— Massimo
source

en fait, j'ai un serveur avec 2x quad core avec 8 Go de RAM. j'utilise le ram complet et 100% du processeur (il semble que je puisse utiliser 800%, voir ici :) cpu: img834.imageshack.us/img834/3483/downloadv.png ram: img442.imageshack.us/i/ Disque download2p.png : img213.imageshack.us/i/download1x.png merci

Sur la base de ces graphiques, vous n'utilisez qu'un (ou au plus deux) de vos cœurs de processeur; donc votre application n'est certainement pas liée au processeur ... ou c'est le cas, mais il est impossible de tirer parti de plusieurs processeurs. En outre, tous que la mémoire utilisée pour « cache » n'est pas actully nécessaire par personne, c'est juste l'avantage de la prise de l' OS de celui - ci parce que « il est là ».

— Massimo

comment puis-je trouver des informations sur l'utilisation de tous les cœurs de processeur? J'utilise une lampe ...

Tout d'abord, vous devez vérifier si vous ne les utilisez pas car ils ne sont tout simplement pas nécessaires (= faible charge), parce que vos opérations ne peuvent pas être correctement parallélisées, ou parce que MySQL et / ou Apache ne sont pas configurés pour Utilise les. Et, comme ces deux programmes sont généralement multithread par défaut, j'aurais un aperçu de la charge de votre serveur et de vos requêtes SQL ...

— Massimo

3

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.

— Joris
source

oui c'est un site web complexe, c'est une communauté, je ne peux rien mettre en cache, ça change à chaque seconde. J'ai essayé de mettre en cache des pages, mais le taux de réussite du cache était proche de 0, car chaque fois que je mets en cache une page, elle ne peut jamais être lue à nouveau, ou elle peut changer avant de la rouvrir. merci

4

Il y a très peu de sites inaccessibles; si cela ne change que toutes les secondes, vous pouvez toujours mettre en cache pendant une seconde entière, comme 10 pages vues ;-) Avez-vous envisagé de ne pas mettre en cache les pages entièrement, mais plutôt des blocs ou des valeurs spécifiques, etc.? Vous pouvez mettre en cache en dehors de la base de données, sur des segments de mémoire partagée, système de fichiers, memcached. De plus, généralement dans une telle situation, ESI pourrait être utile

— Joris

0

A en juger par vos commentaires, le facteur le plus important 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.

— Elliott
source

0

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. Parcourez, c'est généralement une saveur que vous pouvez interfacer assez facilement avec le code existant, ce qui empêchera également les brûlures d'estomac de manquer d'espace de cache.

— BHGalyean
source

0

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, la taille des données est inférieure à la mémoire du serveur (ce qui réduit considérablement les E / S et améliore considérablement les performances).

J'utilise une mémoire d'un processeur de 3,75 Go, 100 Go de SSD, une instance de serveur mysql cloud gcp 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.

— homme de bronze
source

écrire le résultat du test qps (2018-11) gcp mysql 2cpu 7,5 Go de mémoire 150 Go de sérialisation ssd écrire 10 threads, 30k d'écriture de ligne par sql, 7,0566 Go de table, la longueur de la clé de données est de 45 octets et la longueur de la valeur est de 9 octets, obtenez 154 Ko de lignes écrites par seconde, le processeur 97,1% écrit qps 1406 / s dans la console gcp.

— homme de bronze