Qu'est-ce qu'une mesure réaliste pour tester une application Web CMS?

Question

Notre société rencontre des difficultés avec notre application web CMS. Cette application a été partiellement construite par un entrepreneur et nous avons été confrontés à des problèmes de stabilité (écrasement, avoir à les mettre en face des équilibreurs de charge ou des mécanismes de mise en cache) lorsque nous pensons que l'application devrait être capable de gérer. Nous avons mis au point une mesure standard minimale, mais nous ne savons pas si ces mesures sont réalistes.

Nous espérions obtenir dans ce forum des commentaires sur ce qu'une attente réaliste d'un système CMS devrait gérer indépendamment de la technologie qui a été construite. Donc, si la même application devait être construite en .NET au lieu de Java (courant), vous vous attendez à faire la même chose.

Les mesures que nous sommes arrivés avec sont:

• Nombre de demandes/longueur de la file d'attente simultanées: 100 maximum
• temps pour servir une demande: 2 de minimum
• Nombre de demandes par heure: 150 000
• nombre minimum de pages vues par heure: 5000

Exigences minimales HD: -2 Go Ram - 2 Dual-Core 2.0 Ghz

Fonctionnalité générale:

• Croix dynamique Référencer (Personnes à Nouvelles, événements aux personnes et aux Nouvelles, Cas techniques, etc.)
• Recherche avancée Caractéristiques
• hautement configurable sans programmation

Answer 1

Il est pas raisonnable de faire du béton attentes performances & évolutivité sans aucune information sur le matériel, la technologie, la charge, l'utilisation, etc. « CMS » est très large:

• Qu'est-ce que votre batterie de serveurs ressemble?
• Quelles sont les conditions de votre SLA?
• À quoi ressemble votre utilisateur? Par exemple. beaucoup d'utilisateurs brefs ou moins d'utilisateurs avec de longues sessions et beaucoup de demandes?

Autres questions importantes pour répondre:

• Voulez-vous mesurer « le temps de premier octet » (je déteste cela, mais il est assez commun), ou comprennent la latence du réseau dans votre total « temps pour servir "?
• Combien d'éditeurs travaillent sur le système?
• Vos éditeurs utilisent-ils le même support de données ou préparent-ils le contenu dans un environnement isolé et transmettent-ils des lots de mises à jour de contenu?
• Quel type de mécanisme de mise en cache pouvez-vous prendre en charge? Le contenu peut-il être périmé pendant des minutes/heures?

Dans notre ferme de plusieurs équilibrage de charge des serveurs 64 bits avec ~ RAM 32gb (IIRC) et 4 processeurs chacun, nous avons en moyenne un peu moins de 100k demandes par heure avec une charge maximale de plusieurs centaines de demandes/sec (hors du commun). Le temps de chargement total de l'utilisateur final (y compris les images et les ressources) doit être inférieur à 5 secondes. Notre base de données de contenu CMS totalise un peu moins de 750 000 pages. Nous avons des quantités massives de contenu à chargement croisé, des requêtes, des widgets configurables par éditeur, etc.

Answer 2

Ce que vous devriez commencer à faire est de suivre la façon dont les gens l'utilisent. Si vous conservez des weblogs, vous aurez des requêtes dans le temps et un nombre de sessions actives etc.

Vous devez ensuite utiliser ces métriques pour déterminer à quoi doivent ressembler vos tests de charge/stress. Combien d'utilisateurs à la fois, chargez le test aux niveaux de transaction de pointe - mise à zéro pour les lectures par rapport aux écritures.

Answer 3

Il est très difficile de répondre à votre question. Vous avez mentionné le matériel de votre serveur, mais ce n'était pas clair pour moi si ce matériel est utilisé sur le serveur de base de données ou sur le serveur d'applications (ou si vous utilisez le même matériel pour les deux). Et vous ne nous avez pas fourni d'informations concernant votre base de données ...

Il est encore plus difficile de vous aider sans connaître l'architecture de votre application. Certaines décisions architecturales, comme la mise en cache de bases de données, les techniques avancées d'optimisation frontale, l'optimisation de base de données, l'indexation de texte intégral et le traitement asynchrone (via Message Queues) peuvent faire une énorme différence.

Quoi qu'il en soit, je vous recommande d'utiliser des outils de test de charge comme JMeter, soie Peformer, Load Runner, etc.

Answer 4

Notre société utilise coureur de charge avec 3 ensembles différents de scripts. 1 script est d'imiter un cas d'utilisation de base pour le site web, la page principale, la connexion, la navigation à la zone de sujet, etc ... le deuxième script est de faire une recherche de site aléatoire basée sur 100 termes de recherche possibles. et le troisième test est pour un cas d'utilisation d'une réponse à un e-mail de masse à nos abonnés.

chaque script, nous répétons l'action 20 fois.

Nous exécutons le 1er script à 100 utilisateurs simultanés commençant par 1 utilisateur augmentant par 5 toutes les 30 secondes et nous laissons courir et nous tirons les statistiques.

Nous courons le 2ème script à 20 utilisateurs simultanés en commençant par 1 utilisateur augmentant de 2 toutes les 30 secondes

Nous courons le 3ème script à 500 utilisateurs simultanés en commençant par 1 et en augmentant de 10 toutes les 5 secondes. La partie importante est que nous effectuons le même test de charge et suivons/analysons les résultats à chaque modification de l'infrastructure. Charge de charge suit le temps de réponse, les taux de défaillance et quelques autres statistiques ... avec les agents distants, il peut également suivre la base de données et les paramètres vitaux du serveur.

Answer 5

Les problèmes de performances sont rarement simples. Franchement parlant, vous devriez vraiment prendre les services d'un intégrateur qualifié, connaissant à la fois le CMS que vous utilisez et l'optimisation des performances. Il est toujours difficile de trouver les goulots d'étranglement entre le réseau/le CMS lui-même/sa mise en œuvre.Vos spécifications me semblent assez "standard", rien d'attendu ici, donc je suspecte plus de problèmes de mise en œuvre ou de réseau que directement le CMS (je ne peux pas dire que ce n'est pas le CMS, je veux dire, ça serait être surprenant ... et décevant.Si c'est un fournisseur de sources proches bien connu, un célèbre éditeur open source, vos chances que le CMS ne soit pas la cause se déplacent rapidement).