2009-04-28 11 views
4

Unser Unternehmen steht vor einigen Schwierigkeiten mit unserer CMS-Webanwendung. Diese Anwendung wurde teilweise von einem Auftragnehmer erstellt und wir haben einige Stabilitätsprobleme (Abstürze, vor Load Balancer oder Caching-Mechanismen) konfrontiert, wenn wir denken, dass die Anwendung in der Lage sein sollte, damit umzugehen. Wir haben eine minimale Standardmessung zusammengestellt, aber wir wissen nicht, ob diese Metriken realistisch sind.Was ist eine realistische Messung, um eine CMS-Webanwendung zu laden?

Wir hatten gehofft, in diesem Forum Feedback zu bekommen, was eine realistische Erwartung eines CMS-Systems ist, unabhängig von der Technologie, die gebaut wurde. Wenn also die gleiche Anwendung in .NET anstatt in Java (aktuell) erstellt werden sollte, werden Sie wahrscheinlich dasselbe ausführen.

Die Metriken, die wir kamen mit sind:

  • Anzahl der gleichzeitigen Zugriffe/Warteschlangenlänge: 2 s Mindest
  • Anzahl der Anfragen pro Stunde: 100 Maximale
  • Zeit eine Anfrage zu dienen: 150.000
  • Mindestanzahl der Seitenaufrufe pro Stunde: 5.000

Minimum HD-Anforderungen: -2 GB Ram - 2 Dual-Core 2,0 Ghz

Allgemeine Funktionalität:

  • dynamische Querverweise (Menschen zu News, Events zu Menschen und News, Technische Fälle, usw.)
  • Erweiterte Suche Eigenschaften
  • in hohem Maße konfigurierbar ohne Programmier
+1

Zeit für eine Anfrage: 2 s Minimum Sollte es nicht maximal 2 s dauern? – razenha

Antwort

1

Es ist nicht vernünftig zu konkretisieren Leistung & Skalierbarkeit Erwartungen ohne Informationen über Hardware, Technologie, Last, Nutzung etc. „CMS“ ist sehr breit:

  • Was ist der Serverfarm aussehen?
  • Was sind die Bedingungen Ihres SLA?
  • Wie sieht Ihr typischer Benutzer aus? Z.B. viele kurze Benutzer oder weniger Benutzer mit langen Sitzungen und vielen Anfragen?

Weitere wichtige Fragen zu beantworten:

  • Wollen Sie „Zeit bis zum ersten Byte“ messen (ich hasse das, aber es ist ziemlich verbreitet) oder umfassen Netzwerk-Latenz in Ihrem gesamten „Zeit zu dienen "?
  • Wie viele Editoren arbeiten gegen das System?
  • Arbeiten Ihre Redakteure mit der gleichen Datensicherung oder bereiten sie Inhalte in einer isolierten Umgebung vor und schieben Chargen von Inhaltsupdates?
  • Welche Art von Caching-Mechanismus können Sie unterstützen? Kann der Inhalt für Minuten/Stunden veraltet sein?

In unserem Hof ​​von mehreren Lastenausgleich 64-Bit-Server mit ~ 32gb RAM (IIRC) und 4 CPUs jeweils durchschnittlich wir knapp 100k Anfragen pro Stunde mit einer Spitzenlast von mehreren hundert Anfragen/s (ungewöhnlich). Die Gesamtladezeit der Endbenutzer (inkl. Bilder und Assets) muss weniger als 5 Sekunden betragen. Unsere gesamte CMS-Inhaltsdatenbank umfasst knapp 750.000 Seiten. Wir haben riesige Mengen von Cross-Loaded-Inhalten, Abfragen, komplexen Editor-konfigurierbaren Widgets usw.

+0

Die meisten Fragen, die Sie gestellt haben, haben wir. Wir entwickeln die Architektur unseres Hosting-Mechanismus neu. Unser SLA enthält diese Informationen nicht, aber wir wollen uns realistische Zahlen einfallen lassen. Ihr Beitrag war gut, um uns eine relative Vorstellung davon zu geben, wo wir sind. – Geo

1

Was Sie tun sollten, ist zu verfolgen, wie Menschen es verwenden. Wenn Sie Weblogs führen, haben Sie Anfragen im Laufe der Zeit und Anzahl der aktiven Sitzungen usw.

Sie sollten diese Metriken dann verwenden, um zu bestimmen, wie Ihr Belastungs-/Stresstest aussehen sollte. Wie viele Benutzer gleichzeitig testen Sie es bei Spitzentransaktionslevels - für Lesevorgänge im Vergleich zu Schreibvorgängen.

0

Es ist sehr schwer, Ihre Frage zu beantworten. Sie erwähnten die Hardware Ihres Servers, aber es war mir nicht klar, ob diese Hardware für den Datenbankserver oder für den Anwendungsserver verwendet wird (oder wenn Sie für beide die gleiche Hardware verwenden). Und Sie haben uns keine Informationen über Ihre Datenbank geliefert ...

Es ist noch schwieriger zu helfen, ohne Ihre Anwendungsarchitektur zu kennen. Einige Architekturentscheidungen wie Datenbank-Caching, erweiterte Front-End-Optimierungstechniken, Datenbankoptimierung, Volltextindex und asynchrone Verarbeitung (über Message Queues) können die Performance und Skalierbarkeit der Anwendungen enorm verbessern.

Wie dem auch sei, empfehle ich Ihnen einige Lasttest-Tools wie JMeter zu verwenden, Seide Peformer, Last Runner etc.

0

Unsere Firma Last Läufer mit 3 verschiedenen Sätzen von Skripten verwendet. Ein Skript soll einen grundlegenden Anwendungsfall für die Website, die Hauptseite, das Anmelden, die Navigation zum Themenbereich usw. nachahmen. Das zweite Skript besteht darin, eine zufällige Seitensuche basierend auf 100 möglichen Suchbegriffen durchzuführen. und der 3. Test ist für einen Anwendungsfall einer Antwort auf eine Massen-E-Mail an unsere Abonnenten.

jedes Skript wiederholen wir die Aktion 20 mal.

Wir führen das 1. Skript bei 100 gleichzeitigen Benutzern beginnend mit 1 Benutzer um 5 alle 30 Sekunden und wir lassen das laufen und wir ziehen die Statistik.

Wir führen das zweite Skript bei 20 gleichzeitigen Benutzern mit 1 Benutzer beginnend von 2 alle 30 Sekunden

Erhöhung Wir führen die 3. Skript bei 500 gleichzeitigen Benutzern beginnend mit 1 und 10 all 5 Sekunden erhöht.

Der wichtige Teil ist, dass wir den gleichen Belastungstest durchführen und die Ergebnisse bei jeder Änderung der Infrastruktur verfolgen/analysieren.

Load-Runner verfolgt die Antwortzeit, Fehlerraten und ein paar andere Statistiken ... mit Remote-Agenten kann es die Datenbank und Server-Vitalwerte auch verfolgen.

0

Leistungsprobleme sind selten unkompliziert. Ehrlich gesagt, sollten Sie wirklich die Dienste eines erfahrenen Integrators in Anspruch nehmen, der sowohl BEIDE CMS als auch Leistungsoptimierung kennt. Es ist immer schwierig herauszufinden, welche Engpässe zwischen dem Netzwerk/dem CMS selbst/seiner Implementierung bestehen.

Ihre Spezifikationen sehen für mich ziemlich "Standard", nichts Erwartungsvolles hier, so vermute ich mehr die Implementierung oder Netzwerkprobleme als direkt das CMS (ich kann nicht sagen, es ist nicht das CMS, möchte ich sagen, dass würde sei überraschend ... und enttäuschend: Wenn es ein bekannter Close-Source-Anbieter ist, ein bekannter Open-Source-Anbieter, steigen deine Chancen, dass das CMS nicht die Ursache ist, schnell an.