Quelle est la "moyenne" des demandes par seconde pour une application Web de production?

Question

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

Answer 1

OpenStreetMap semble avoir de 10 à 20 par seconde

Wikipedia semble être 30000 à 70000 par seconde , réparties sur 300 serveurs (de 100 à 200 requêtes par seconde par la machine, dont la plupart sont des caches)

Présence devient de 7000 images par semaine (1 télécharger par 95 secondes)

Answer 2

Pas sûr que quelqu'un est toujours intéressé, mais cette information a été posté sur Twitter:

Les Stats

• Plus de 350 000 utilisateurs. Les chiffres réels sont, comme toujours, très super super top secret.
• 600 demandes par seconde.
• Moyenne de 200 à 300 connexions par seconde. Dopage à 800 connexions par seconde.
• MySQL traitées de 2 400 demandes par seconde.
• 180 Rails instances. Utilise des Bâtards comme le "web server".
• 1 Serveur MySQL (un grand 8 de base de la boîte) et 1 esclave. L'esclave est en lecture seule pour les statistiques et les rapports.
• 30+ processus de traitement des petits boulots.
• 8 Le Soleil X4100s.
• Le traitement d'une demande en 200 millisecondes dans les Rails.
• La moyenne de temps passé dans la base de données est de 50 à 100 millisecondes.
• Plus de 16 GO de memcached.

Answer 3

Lorsque je vais dans le panneau de contrôle de mon hébergeur, ouvrir phpMyAdmin, puis cliquez sur "Afficher MySQL les informations d'exécution", j'obtiens:

Ce serveur MySQL a été en cours d'exécution pour 53 jours, 15 heures, 28 minutes et 53 secondes. Il a débuté sur Oct 24, 2008 à 04:03.

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

C'est un moyen de 743 requêtes mySQL chaque seconde pour le passé 53 jours!

Je ne sais pas pour vous, mais pour moi c'est rapide! Très vite!!

Answer 4

personnellement, j'aime à la fois l'analyse effectuée à chaque fois....requêtes/seconde et le temps moyen/demande et de l'amour de voir le max de temps de demande ainsi que sur le dessus de cela. il est facile d'inverser si vous avez 61 requêtes/seconde, vous pouvez ensuite il suffit de retourner à 1000ms / 61 demandes.

Pour répondre à votre question, nous avons fait une énorme charge de nous tester et de trouver des plages sur les différentes amazon le matériel que nous utilisons(meilleure valeur 32 bits support cpu quand il est descendu à $$ / événement / seconde) et nos demandes / secondes variait de 29 requêtes / seconde / node jusqu'à 150 requêtes/seconde/nœud.

Donner meilleur matériel de cours donne de meilleurs résultats mais pas le meilleur retour sur investissement. De toute façon, ce post était super comme je l'ai été à la recherche pour certains parallèles pour voir si mes numéros où dans le stade et partagé la mienne au cas où quelqu'un d'autre est à la recherche. Le mien est purement chargé aussi haut que je peux aller.

NOTE: grâce à des requêtes/seconde analyse(pas ms/demande), nous avons trouvé un linux majeures problème que nous essayons de résoudre linux(nous avons testé un serveur en C et java) gèle tous les appels dans la douille bibliothèques sous trop de charge qui semble très étrange. L'article complet peut être trouvé ici, en fait.... http://ubuntuforums.org/showthread.php?p=11202389

Nous sommes encore en train d'essayer de résoudre cela, car il nous donne un énorme gain de performance dans notre test va de 2 minutes 42 secondes à 1 minute 35 secondes lorsque cela est fixe donc nous voir un de 33% performancce amélioration....pour ne pas mentionner, le pire de l'attaque de DoS est le plus ces pauses sont de sorte que tous les processeurs tomber à zéro et arrêt de traitement...à mon avis, le serveur de traitement devrait continuer dans le visage de DoS, mais pour une raison quelconque, il se fige à chaque fois dans un tandis que le Dos parfois jusqu'à 30 secondes!!!

PLUS: Nous avons constaté qu'il s'agissait en fait d'un jdk condition de course bug....difficile d'isoler sur les grands groupes, mais quand nous avons couru 1 serveur 1 nœud de données mais 10 d'entre eux, nous avons pu reproduire à chaque fois ensuite et juste regardé le serveur/datanode elle s'est produite. La commutation du jdk à une version antérieure résolu le problème. Nous étions sur le jdk1.6.0_26 je crois.

Answer 5

Ce n’est pas vraiment une question à laquelle on peut répondre: Amazon va avoir des différences d’ordre de grandeur par rapport à un site de niche en dynamique des fluides.