Je n'ai aucun cadre de référence en ce qui concerne ce qui est considéré comme «rapide»; Je me suis toujours demandé cela mais je n'ai jamais trouvé de réponse claire ...

OpenStreetMap semble avoir 10-20 par seconde

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

Geograph reçoit 7000 images par semaine (1 téléchargement toutes les 95 secondes)

Je ne suis pas sûr que quelqu'un soit toujours intéressé, mais cette information a été publiée sur Twitter (et ici aussi ):

Les statistiques

• Plus de 350 000 utilisateurs. Les chiffres réels sont, comme toujours, très super top secret.
• 600 requêtes par seconde.
• 200 à 300 connexions par seconde en moyenne. Augmentation de 800 connexions par seconde.
• MySQL a traité 2 400 requêtes par seconde.
• 180 instances de Rails. Utilise Mongrel comme serveur "web".
• 1 serveur MySQL (une grande boîte à 8 cœurs) et 1 esclave. L'esclave est en lecture seule pour les statistiques et les rapports.
• 30+ processus pour gérer les petits travaux.
• 8 Sun X4100.
• Traitez une demande en 200 millisecondes dans Rails.
• Le temps moyen passé dans la base de données est de 50 à 100 millisecondes.
• Plus de 16 Go de mémoire cache.

Lorsque je vais dans le panneau de configuration de mon hébergeur, ouvre phpMyAdmin et clique sur "Afficher les informations d'exécution MySQL", j'obtiens:

Ce serveur MySQL fonctionne depuis 53 jours, 15 heures, 28 minutes et 53 secondes. Il a démarré le 24 octobre 2008 à 04h03.

Statistiques des requêtes: depuis son démarrage, 3 444 378 344 requêtes ont été envoyées au serveur.

Total 3444 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 les deux analyses effectuées à chaque fois .... demandes / seconde et temps moyen / demande et j'adore voir le temps maximum de demande en plus de cela. il est facile de retourner si vous avez 61 requêtes / seconde, vous pouvez alors simplement le retourner à 1000ms / 61 requêtes.

Pour répondre à votre question, nous avons fait un énorme test de charge nous-mêmes et trouvons qu'il varie sur divers matériels Amazon que nous utilisons (la meilleure valeur était le processeur moyen 32 bits quand il s'agissait de $$ / événement / seconde) et nos demandes / secondes variait de 29 demandes / seconde / nœud à 150 requêtes / seconde / nœud.

Donner un meilleur matériel donne bien sûr 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 se situaient dans le stade approximatif et partageaient également le mien au cas où quelqu'un d'autre chercherait. Le mien est purement chargé aussi haut que je peux aller.

REMARQUE: grâce à l'analyse des requêtes / seconde (pas ms / requête), nous avons trouvé un problème majeur de Linux 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 sockets lorsqu'il est sous trop de charge 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 des performances dans la mesure où notre test passe de 2 minutes 42 secondes à 1 minute 35 secondes lorsque cela est corrigé, nous constatons donc une amélioration de 33% des performances .... sans oublier, plus l'attaque DoS est mauvaise, plus ces pauses sont longues pour que tous les processeurs tombent à zéro et arrêtent le traitement ... à mon avis, le traitement du serveur devrait continuer face à un DoS mais pour une raison quelconque, il se fige de temps en temps pendant le Dos parfois jusqu'à 30 secondes !!!

ADDITION: Nous avons découvert qu'il s'agissait en fait d'un bogue de condition de course jdk .... difficile à isoler sur les gros clusters, mais lorsque nous avons exécuté 1 nœud de données serveur 1 mais 10 de ceux-ci, nous pouvions le reproduire à chaque fois et simplement regarder le serveur / datanode sur lequel il s'est produit. Le basculement du jdk vers 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 du type pommes aux oranges.

Vous demandez 1. la charge de demande moyenne pour une application de production 2. ce qui est considéré comme rapide

Ceux-ci ne se rapportent 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 pages qu'ils effectuent par seconde

c. le nombre de requêtes supplémentaires (ex. appels ajax, etc.)

Quant à ce qui est considéré comme rapide ... voulez-vous dire combien de requêtes un site peut accepter? Ou si un matériel est considéré comme rapide s'il peut traiter xyz # de requêtes par seconde?

Notez que les graphiques de taux de réussite seront des modèles sinusoïdaux avec des «heures de pointe» peut-être 2x ou 3x le taux que vous obtenez pendant que les utilisateurs dorment. (Peut être utile lorsque vous planifiez le traitement quotidien par lots sur les serveurs)

Vous pouvez voir l'effet même sur des sites `` internationaux '' (multilingues, localisés) comme wikipedia

moins de 2 secondes par utilisateur généralement - c'est-à-dire que les utilisateurs qui voient des réponses plus lentes que cela pensent que le système est lent.

Maintenant, dites-moi combien d'utilisateurs vous avez connectés.

Vous pouvez rechercher «analyse d'effet slashdot» pour des graphiques de ce que vous verriez si un aspect du site devenait soudainement populaire dans les actualités, par exemple ce graphique sur wiki .

Les applications Web qui survivent ont tendance à être celles qui peuvent générer des pages statiques au lieu de soumettre chaque requête à un langage de traitement.

Il y avait une excellente vidéo (je pense que cela aurait pu être sur ted.com? Je pense que cela aurait pu être par l'équipe Web de Flickr? Quelqu'un connaît-il le lien?) Avec des idées sur la façon de faire évoluer les sites Web au-delà du serveur unique, par exemple, comment allouez des connexions parmi la combinaison de serveurs en lecture seule et en lecture-écriture pour obtenir le meilleur effet pour différents types d'utilisateurs.