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.
