Questions & Answers

[JSydow]

Hallo zusammen,

Ich stehe gerade vor der Aufgabe einen Perfomance Test von First Spirit CMS durchzuführen.
Ziel des Tests:

Es soll ermittelt werden wieviele Redakteure sich gleichzeitig einloggen und Ihre Bereiche bearbeiten können. (HTML sowie JAVA Client)
Der Hintergrund: Ermittlung ob die vorhanden Hardware Ressourcen ausrreichen.

Erster Testansatz:

Über die Access API sollen folgende Zugriffe erfolgen:

- Anmeldung eines Benutzers

- Aufruf der benötigten Seite

- Bearbeitung des Contents

     Die Daten für die Bearbeitung stammen aus einem Dokument  (test.txt) oder werden im Falle von Bilder direkt angegeben.
     Aus dem Text Dokument werden einzelne Char entnommen und in den Content (mit Zeitverzögerung die das Eintippen simulieren) eingepflegt.

     Das Einpflegen soll solange erfolgen bis der Test abgebrochen wird (Text wird innerhalb des Tests auch wieder gelöscht das der Contnent im üblichen Rahmen bleibt).  

Danach werden schrittweise neue Benutzer am System angemeldet die eine andere Seite bearbeiten.

Die Programmierung des Test erfolgt in Java.

Nun meine Frage:

Bevor ich mich in die Access API einarbeite würde mich interessieren ob man dies überhaupt durch die API lösen kann.
Anregungen und Hinweise nehme ich gerne entgegen.

[arnbae]

Hallo,

ein interessantes Thema und ein interessanter Ansatz. Meine Äußerung ist aber nur als Meinung eines Anwenders zu sehen - e-spirit hat da sicherlich grundsätzlichere Antworten parat.

Aus meiner Erfahrung mit der API aus dem Client heraus kann man alles ab "Aufruf ..." (siehe Liste) in einem Client-Script innerhalb des Java-Clients laufen lassen. Man hat dann auch realistische Bedingungen, weil das Client-Script ja nichts anderes macht als des User, wenn er den Java-Client verwendet - von der lokalen Darstellung der Client-GUI mal abgesehen, aber das sollte im Server- Lasttest eh keine Rolle spielen.

Aus meiner Sich kann man damit aber nicht:

• Automatisch einen User anmelden. Das Client-Script läuft im User-Context, mit der Anmeldung des Users.
• Den Webedit-Client (und damit den Overhead für die Erzeugung des HTML-Outputs) testen. Selbst wenn der Client Script-fähig ist, laufen trotzdem die Scripte ohne Update der HTML-Ausgabe ab, und manipulieren nur die Datenbasis auf dem Server.

Natürlich könnte man einen solchen Lasttest auch serverseitig als Modul realisieren, aber da stellt sich dann die Frage, wie aussagekräftig das in Bezug auf die Praxis ist, weil beispielsweise die Netzwerk-Kommunikation und die lokale Speicherverwaltung des Clients als Faktoren wegfallen.

Evtl. könnte man auch ein Java-Standalone-Programm schreiben und die API-Klassen verwenden - auch da stellt sich mir aber die Frage nach der Ausagekraft, d.h. WAS testet man denn damit überhaupt?

Deshalb auch meine Antwort - mich würde interessieren, was als Test Sinn macht. Bei uns (fast nur Verwendung des Java-Clients) würde ich das so machen: Client-Script mit den entsprechenden Manipulationen schreiben, Projekt auf 3-4 Rechnern jeweils in 3-4 Clients laden, dann nach und nach in den Clients starten und sehen, was auf dem Server passiert. Gleichzeitig würde ich in den Clients die Reaktionszeiten des Servers loggen.

[feddersen]

Um den JavaClient zu simulieren, würde man die Access-API verwenden. Einfach entsprechend viele Connections zum Server aufbauen und die gewünschten Aktionen durchführen (Anlegen von Inhalten, bearbeiten, löschen etc.). Das machen wir bei unseren Tests auch so.

Man testet damit natürlich nicht die Oberfläche des JavaClients, sondern ob bei einer bestimmten Zahl von Objekten im System die Performance leidet (Aktionen dauern länger) oder wie das System skaliert (bei X gleichzeitigen Operationen entstehen Bottlenecks, Speicherprobleme etc.).

Den WebClient testet man wie eine klassische Webapplikation. Zum Beispiel per JMeter und entsprechender Logik um die Formulare abzuschicken und Buttons zu klicken. Selenium und Konsorten kann man natürlich auch verwenden. Hier testet man primär die Ladezeiten der Seiten und ab welcher Anzahl von gleichzeitigen Anfragen das System einbricht.

Eventuell ist es sinnvoll vorher noch mal mit uns Rücksprache zu halten. Es wurden erst kürzlich, im Rahmen eines Auswahlprozesses, Tests durchgeführt. Vielleicht sind diese Ergebnisse schon ausreichend, wobei ich erst in Erfahrung bringen muss, ob wir diese weitergeben dürfen. Sie wurden von einer anderen Firma durchgeführt und ausgewertet. In der Regel stehen wir bei solchen Szenarien beratend zur Seite, damit gewährleistet ist, dass die Tests auch ihren Anforderungen entsprechen  und somit aussagekräftig sind.

[JSydow]

Verhält sich die Simulation des Java Clients über die Access API genauso wie ein tatsächlich eingeloggter User?

Sprich der Datenverkehr zwischen Javaclient bzw. Access API und dem Server sollte in beiden Fällen gleich sein.

Gerne halte ich auch Rücksprache mit Ihnen bezüglich der Tests, vorausgesetzt Sie dürfen die Ergebnisse bekannt geben.

[Peter_Jodeleit]

Der Java-Client benutzt die API, d.h. mann kann mit einem API-basiertem Test das Verhalten ziemlich genau simulieren. Natürlich hat der JC an einigen Stellen ein zusätzliches Caching (z.B. werden Knoten über die offenen Arbeitsbereiche referenziert und dadurch nicht vom Garbage Collector weggeräumt). Aber auch das kann man simulieren, bzw. wenn man es nicht macht ergibt sich durch den Test eben ein etwas schlechteres Bild, als man es in der Realität bekommen würde (weil z.B. häufiger nachgeladen wird).

[isenberg]

Hallo Herr Sydow,

zusätzlich zu den Hinweisen zu den Tests über die API, hier einige Informationen zu anderen Testmöglichkeiten:

Um die Auslastung durch viele parallel arbeitende Redakteure am Web- und Java-Client zu simulieren verwenden wir intern und auch bei Kunden folgende Software:

Web-Client: JMeter: http://jakarta.apache.org/jmeter/

Java-Client: QF-Test: http://www.qfs.de/

JMeter kann auf einem normalen Desktop-Rechner (2-4 CPU-Cores, 16 GByte RAM) schon mehrere hundert parallel aktive Redakteure simulieren. Die Erstellung eines Testskripts ist aber zeitaufwendig und benötigt für jemanden, der sich bereits allgemein mit JMeter auskennt ca. 1 PT pro zu simulierendem Arbeitsschritt, wobei ein Arbeitsschritt z.B. das Erstellen einer neuen Seite und Eingabe von Text wäre.

QF-Test für den Lasttest mit Java-Client erfordert mehr Hardware-Ressourcen, da eine Instanz des Java-Client ca. 200 MByte RAM benötigt und ca. 5 Clients pro CPU-Core im Normalbetrieb akzeptabel sind. Die Erstellung des Testskript ist dann aber relativ einfach, da QF-Test im Gegensatz zu JMeter einfach zu bedienen ist und man den Client beim Erstellen direkt sieht, und damit ca. um den Faktor 5 schneller als bei JMeter. Der Hersteler bietet auf Anfrage zeitbeschränkte Lizenzen von z.B. nur wenigen Wochen an, so dass die Kosten überschaubar sind.

[JSydow]

Vielen Dank für die hilfreichen Antworten.

Aufgrund der sehr spärlichen Beschreibung der Access API habe ich nun schon verschiedene andere Möglichkeiten ausprobiert aber bisher ohne Erfolg.

Über HTML (selenium) und den Java standalone Client (Eclipse Jubula) komme bis zur Editier Funktion eines Contents.

Einloggen>Seite aufrufen>Content auswählen>in den Editmodus wechseln

Innerhalb der Editierfunktion kann ich alle Inhalte ansprechen (Überschrift, Fett, Kursiv usw.) nur die eigentliche Editierbox kann ich nicht ansprechen (eintragen des angezeigten Textes).

Hier ist mit allen Tools Schluß da diese Box nicht erkannt wird.

Hat hier noch einer eine Idee wie ich dies ohne die Access API lösen könnte?

[isenberg]

> Hat hier noch einer eine Idee wie ich dies ohne die Access API lösen könnte?

Siehe meine Antwort vom 08.08.2011 14:04. Bei Verwendung der beschriebenen externen Standard-Software zum Test von Web-Anwendungen oder Java-Anwendungen ist keine Kenntnis der API notwendig.