Quelle est la "moyenne" des demandes par seconde pour une application Web de production?
Je n'ai pas de cadre de référence pour ce qui est considéré comme "rapide"; Je m'étais toujours demandé cela, mais je n'avais jamais trouvé de réponse directe ...
OpenStreetMap semble avoir 10-20 par seconde
Wikipedia semble être 000 à 70000 par seconde réparti sur 0 serveurs (100 à 200 requêtes par seconde et par machine, dont la plupart sont des caches)
Le géographe devient 7000 images par semaine (1 téléchargement toutes les 95 secondes)
Pas sûr que quelqu'un soit toujours intéressé, mais cette information a été postée à propos de Twitter (et ici aussi ):
Les statistiques
- Plus de 350 000 utilisateurs. Les chiffres réels sont, comme toujours, très super super secrets.
- 600 demandes par seconde.
- Moyenne 200-300 connexions par seconde. Pointage à 800 connexions par seconde.
- MySQL a traité 2 400 requêtes par seconde.
- 180 Rails instances. Utilise Mongrel comme serveur "Web".
- 1 serveur MySQL (1 grosse boîte à 8 coeurs) et 1 esclave. Slave est en lecture seule pour les statistiques et les rapports.
- Plus de 30 processus de traitement de travaux impairs.
- 8 Sun X4100.
- Traiter une demande en 200 millisecondes dans Rails.
- Le temps moyen passé dans la base de données est compris entre 50 et 100 millisecondes.
- Plus de 16 Go de memcached.
Lorsque je vais sur le panneau de configuration de mon hébergeur Web, que j'ouvre phpMyAdmin et que je clique sur "Afficher les informations d'exécution de MySQL", je reçois:
Ce serveur MySQL est ouvert depuis 53 jours, 15 heures, 28 minutes et 53 secondes. Tout a commencé le 24 octobre 2008 à 04h03.
Statistiques sur les requêtes: Depuis son démarrage, 3 444 378 344 requêtes ont été envoyées au serveur.
Total 3 444 M
par heure 2,68 M
par minute 44,59 k
par seconde 743,13
Cela représente une moyenne de 743 requêtes mySQL par seconde au cours des 53 derniers jours!
Je ne sais pas pour vous, mais pour moi c'est rapide! Très vite!!
personnellement, j'aime bien les analyses effectuées à chaque fois ... demandes/seconde et moyenne/demande et j'adore voir le temps de demande maximal. il est facile de retourner si vous avez 61 demandes/seconde, vous pouvez simplement le retourner à 1000 ms/61 demandes.
Pour répondre à votre question, nous avons effectué nous-mêmes un test de charge considérable et avons constaté qu'il est compatible avec les différents matériels Amazon que nous utilisons (le processeur moyen 32 bits est le meilleur rapport qualité-prix en termes de $/événement/seconde) et nos requêtes/secondes. allant de 29 demandes/seconde/nœud à 150 demandes/seconde/nœud.
Bien sûr, un meilleur matériel donne de meilleurs résultats, mais pas le meilleur retour sur investissement. Quoi qu'il en soit, cet article était génial, car je cherchais des parallèles pour voir si mes chiffres étaient dans le stade et partageaient les miens également, au cas où quelqu'un d'autre le regarderait. Le mien est purement chargé aussi haut que je peux aller.
NOTE: grâce à des requêtes/seconde analyse (pas ms/request), nous avons trouvé un problème majeur que nous essayons de résoudre, où Linux (nous avons testé un serveur en C et Java) gèle tous les appels dans les bibliothèques de socket lorsque la charge est trop importante. ce qui semble très étrange. Le message complet peut être trouvé ici en fait .... http://ubuntuforums.org/showthread.php?p=11202389
Nous essayons toujours de résoudre ce problème car cela nous donne une énorme amélioration de performance car notre test passe de 2 minutes 42 secondes à 1 minute 35 secondes lorsque ceci est corrigé, nous constatons donc une amélioration de 33% des performances ... sans parler de, pire est l’attaque par déni de service, plus ces pauses sont longues, de sorte que tous les processeurs tombent à zéro et arrêtent le traitement ... à mon avis, le traitement du serveur devrait se poursuivre malgré un déni de service mais, pour une raison quelconque, il se bloque de temps en temps pendant le dos parfois jusqu'à 30 secondes !!!
ADDITION: Nous avons découvert qu’il s’agissait d’un bogue de condition de concurrence jdk. Difficile à isoler sur de gros clusters, mais lorsque nous avons exécuté 1 nœud de données sur un serveur, mais 10 de ceux-ci, nous pouvions le reproduire à chaque fois et regarder le serveur./datanode il s'est produit sur. Le passage du jdk à une version antérieure a résolu le problème. Nous étions sur jdk1.6.0_26 je crois.
C’est une question très ouverte qui va de l’ordre des pommes à l’orange.
Vous demandez 1. la charge de demande moyenne pour une application de production 2. ce qui est considéré comme rapide
Ceux-ci ne concernent pas nécessairement.
Votre nombre moyen de demandes par seconde est déterminé par
une. le nombre d'utilisateurs simultanés
b. le nombre moyen de demandes de page qu'ils font par seconde
c. le nombre de demandes supplémentaires (par exemple, appels ajax, etc.)
Quant à ce qui est considéré comme rapide, voulez-vous dire combien peu de demandes un site peut prendre? Ou si un matériel est considéré rapide s'il peut traiter xyz # de requêtes par seconde?
généralement moins de 2 secondes par utilisateur - c’est-à-dire que les utilisateurs voient des réponses plus lentes que celles-ci pensent que le système est lent.
Maintenant, vous me dites combien d'utilisateurs vous avez connectés.
Vous pouvez rechercher dans "l'analyse de l'effet slashdot" des graphiques de ce que vous verriez si certains aspects du site sont soudainement devenus populaires dans les actualités, par exemple. ce graphique sur le wiki .
Les applications Web qui survivent ont tendance à être celles qui peuvent générer des pages statiques au lieu de placer chaque requête dans un langage de traitement.
Il y avait une excellente vidéo (je pense que c’était peut-être sur ted.com? Je pense que c’est le cas de l’équipe Web de Flickr? Quelqu'un connaît-il le lien?) Avec des idées sur la manière de redimensionner des sites Web au-delà du serveur unique, par exemple. comment allouer des connexions entre la combinaison de serveurs en lecture seule et en lecture-écriture afin d'obtenir le meilleur effet possible pour différents types d'utilisateurs.
Notez que les graphiques de taux de succès seront des modèles sinusoïdaux avec des "heures de pointe", par exemple 2x ou 3x le taux obtenu lorsque les utilisateurs dorment. (Peut être utile lorsque vous planifiez le traitement quotidien des lots sur les serveurs)
Vous pouvez voir l’effet même sur des sites "internationaux" (tels que wikipedia)