Combien de demandes par minute sont considérées comme "charges lourdes"? (Approximation)
Souvent, les gens discutent de «charge lourde» dans leurs questions (liées à l'optimisation et aux performances).
J'essaie de quantifier cela dans le contexte d'une application Web classique sur un serveur typique (prenons SO et sa relativement petite infrastructure, par exemple) dans un certain nombre de demandes par minute, en supposant qu'elles reviennent immédiatement ( simplifier et éliminer la vitesse de la base de données, etc.).
Je cherche un nombre nominal/une plage, pas "où le CPU atteint son maximum" ou similaire. Une approximation approximative serait très utile (par exemple> 5000/min). Je vous remercie!
Je pense que la bonne réponse à cette question, étant donné que vous ne voulez pas de mesure de charge matérielle (CPU, mémoire, IO utilisation), est que la charge importante est la quantité de demandes par unité de temps à ou sur le nombre maximal de demandes requis par unité de temps.
Le nombre maximal de demandes requis correspond à ce qui a été défini avec le client ou avec le responsable de l’architecture globale.
Disons que X est la charge maximale requise pour l'application. Je pense que quelque chose comme ceci se rapprocherait de la réponse:
0 <charge légère <X/2 <charge régulière <2X/3 <charge élevée <X <= charge lourde
Le problème avec un numéro unique est qu’il n’a aucun rapport avec votre application. Et ce qu’est une lourde charge est totalement, absolument, inélicitement lié à ce que l’application est censée faire.
Bien que 200 demandes par seconde constituent une charge qui occuperait de petits serveurs Web (environ 12 000 par minute).
La charge lourde est ce que votre système ne peut pas gérer. ;-)
Plusieurs centaines de requêtes par seconde.
Le nombre de connexions «from-the-box» ouvertes pour la plupart des serveurs est généralement d'environ 256 ou moins, selon le nombre de requêtes ergo 256 par seconde. Vous pouvez le pousser jusqu'à 2000-5000 pour les requêtes ping ou à 500-1000 pour les requêtes légères. Le rendre encore plus haut est très difficile et nécessite des modifications complètes du réseau, du matériel, du système d'exploitation, de l'application serveur et de l'application utilisateur (voir problème 10k ).
La vitesse de recherche et la latence des disques durs sont d'environ 1 à 10 ms, pour les disques SSD, c'est 0.1-1 ms. Donc, c'est 100-100 000 IOPS. Prenons 100 000 en tant que valeur maximale ( SSD conséquential write )
Normalement, la connexion reste ouverte pendant au moins 1 x latency value ms. La latence d'un client à un serveur est rarement inférieure à 50-100 ms. Par conséquent, seul 100 000/50 = 2000 IOPS peut créer de nouvelles connexions.
Ainsi, 2000 demande ping par seconde de différents clients est la limite supérieure de base pour un serveur normal. Il peut être amélioré en utilisant le disque RAM ou en ajoutant des disques SSD pour augmenter le nombre d'IOPS, en réduisant le nombre de requêtes de routage, en modifiant/modifiant le système d'exploitation afin de réduire la charge du noyau, etc. même client (connexion) et nombre limité de clients. Dans de bonnes conditions, il peut atteindre des centaines de milliers
D'autre part, un ping plus long, un temps d'exécution d'application supérieur, une imperfection du système d'exploitation et du matériel peuvent facilement réduire la valeur de base à plusieurs centaines de requêtes par seconde. En outre, les applications et les serveurs Web classiques ne conviennent généralement pas très bien à une optimisation de haut niveau. La suggestion de Vinko Vrsalovic de 200 est donc très réaliste.
Ce n'est pas une question simple à laquelle on peut répondre avec un simple nombre de demandes/minute.
Dans le secteur des télécommunications, nous effectuons souvent des tests de performance et nous simulons beaucoup d'appels par seconde pour essayer de déterminer la limite. Nous continuons à augmenter le taux d'appels jusqu'à ce que le serveur ne parvienne pas à suivre.
Donc, cela dépend de votre serveur et de ce qu’il peut gérer. Cela dépend aussi de votre perspective. Par exemple, un ancien 386 ne peut traiter que 50 demandes/minute. J'appellerais cela une charge légère. Mais un serveur de haut niveau pourrait être capable de gérer 60000 requêtes/minute. C'est juste deviner. Je ne sais pas si Apache pourrait le faire. Notre logiciel de télécommunication peut certainement.
Je pense qu'il est préférable de répondre à cela du point de vue du serveur. Je dirais que la charge très lourde est lorsque vous arrivez à moins de 10% de ce que votre serveur est capable de gérer sur plusieurs minutes ou dizaines de minutes. Charge lourde à moins de 15%.
Il est difficile de répondre, car la charge ne consiste pas simplement en des demandes par unité de temps. Cela dépend de ce que font ces demandes et de la manière dont elles sont mises en œuvre.
Par exemple, plus de lectures que d'écritures pourraient signifier une charge plus légère.
Le traitement asynchrone des écritures peut signifier une charge plus légère que devoir attendre la fin du traitement synchrone.
Un extrême serait les systèmes de négociation d'actions qui gèrent des milliards de transactions chaque jour de bourse. Examinez le volume typique sur le NYSE ou le NASDAQ et utilisez-le pour estimer une valeur élevée par minute.
Supposons que les transactions 2B au cours d'une journée de négociation sont représentatives du NASDAQ. Les marchés sont ouverts à 9 heures et fermés à 16 heures, soit 7 heures * 3 600 secondes/heure = 25 200 secondes. Cela donnerait une moyenne de 2 transactions/25200 secondes = 79 365 transactions par seconde - une charge très élevée, en effet. Ils utilisent évidemment beaucoup de serveurs, vous aurez donc besoin de ce nombre pour déterminer la charge par serveur.
Si SO peut être considéré comme un bon point de repère, vous pouvez vous interroger sur son volume en méta.
Une charge lourde est tout ce qui est supérieur à ce qui était indiqué dans les exigences. Vous devez savoir comment votre application sera utilisée pour déterminer ce qui peut constituer une charge lourde. Sinon, vous pourriez construire une Ferrari qui ne sera utilisée que pour faire l'épicerie. Grande expérience, mais gaspillage de ressources.