Erstellung eines Lasttest- Frameworks auf Basis von OpenSource Komponenten

Transkript

1 dato Thunstrasse 10 CH-3005 Bern Erstellung eines Lasttest- Frameworks auf Basis von OpenSource Komponenten Thomas Hänni, lic. phil. nat. OpenExpo, März

2 Agenda Kurzvorstellung indato Motivation, Anforderungen Architektur des Frameworks, Komponenten Momentaner Stand Erfahrungen Ausblick

3 indato Gegründet 2000 von Thomas Hänni und Daniel Kühni 5 hochmotivierte MA, davon 4 in der Informatik (entspr. 340 Stellen-%) Gute Aus- und ständige Weiterbildung Wir verfügen über breites Know-how Wir suchen gute Leute zur Verstärkung unseres Teams

4 Warum Lasttests? Erfahrung in Kundenprojekten zeigt, dass sowohl Notwendigkeit wie auch Bedürfnis besteht Wir sind überzeugt, dass auch Kunden von solchen Tests profitieren könnten, die bisher aus Kostengründen darauf verzichtet haben Ausweitung des Kundenkreises auf KMU

5 Welche Art von Angebot? Fixpreis-Angebot für einfache Analysen mit definierten Umfang -> Automatisierung Ziel: in erster Linie KMU -> Kostengünstig Consulting-Dienstleistung für Problemstellungen, die nicht im Standard enthalten sind -> Flexibler Werkzeugkasten

6 Anforderungen (Mindestens) Test von Webanwendungen Daten werden in eine Datenbank eingelesen Definiertes DB-Schema zur Analyse der Daten Automatisierte Erstellung von Standard- Auswertungen als Grafiken Automatisierte Generierung eines Dokument- Skeletts mit Grafiken und Textbausteinen Datengewinnung und Auswertung iterativ Manuelle Nachbearbeitung des Resultats

7 Warum OSS-Komponenten? (I) Einsatz entspricht der Firmenphilosophie Komponenten können als Werkzeugkasten zusammengefasst werden Werkzeugkasten muss nicht von uns gepflegt werden (wirklich? später mehr dazu...) Einzelne Komponenten sind auch in anderem Zusammenhang einsetzbar

8 Warum OSS-Komponenten? (II) Kommerzielle Tools sind sehr teuer (Lizenzgebühren ~120kFr für LoadRunner Web, 500 parallele Benutzer) Herstellerunabhängigkeit (Mercury Interactive von HP übernommen, Bea von Oracle,...) Übernahmeresistenz (Was bisher Open war, bleibt Open)... dies bietet Investitionsschutz

9 Ablauf Textverarbeitung Datenimport Datenbank Report generator Lastgenerator Generiertes Dokument Datengewinnung Erzeugen der Last Messung von Antwortzeiten, etc. Aufzeichnen der Ergebnisse in Logfiles Import der Logs in die Datenbank Datenauswertung Aggregierung der Daten Erstellung von Tabellen und Grafiken Verwendung von Textbausteinen Ansteuerung der Textverarbeitung Generierung des Berichts

10 Komponenten Textverarbeitung Datenimport Datenbank Report generator Lastgenerator Generiertes Dokument BIRT SDK Log4J, JUnit,

11 Architektur: Datengewinnung Browser TCPProxy Testscripts Grinder Console Webserver Grinder Agents Logfiles Datenimport (Perl) Datenbank (PostgreSQL)

12 Architektur: Auswertung der Daten indato Konfiguration Dokumentvorlage Rohdaten + Textbausteine (PostgreSQL) Report generator Textverarbeitung (OpenOffice) Generiertes Dokument Grafik- und Tabellentool (Eclipse BIRT) Standardauswertungen

13 Momentaner Stand Das Framework ist "work in progress", der Report-Generator ein Proof of Concept Bisher wurde auf allen Luxus verzichtet Noch viel Handarbeit, dadurch wenig Zeitersparnis Von der "One-Click-Analyse" sind wir weiter entfernt, als wir uns am Anfang vorgestellt haben

14 Erfahrungen: Funktionalität Prinzipielle Funktionalität in Proof of Concept Qualität lässt sich ziemlich rasch erreichen Um den Funktionsumfang eines kommerziellen Tools zu erreichen, ist viel Arbeit notwendig, selbst wenn auf Eye Candy verzichtet wird Solange der Wille zum Selbermachen da ist, kann praktisch alles gemacht werden, da jede Komponente ersetzt oder ergänzt werden kann

15 Aufstellung der OSS-Lizenzen Komponente Lizenzart Lizenztext The Grinder Grinder License (as is) -> HTTP Client GNU Lesser General Public License LGPL v2.1 -> Jython Python Software Foundation License Version 2, Jython 2.0, 2.1 License, JPython 1.1.x License -> jedit Syntax jedit Syntax copyright and usage statement -> Apache XML Beans Apache 2.0, XMLBeans NOTICE -> Pico Container PicoContainer License Perl GPL 1 oder später ODER Artistic License PostgreSQL BSD style Eclipse BIRT Eclipse Public License OpenOffice SDK OpenOffice LGPL v٣ LGPL v٣

16 OSS-Lizenzen: XML Beans Notice ========================================================================= == NOTICE file corresponding to section 4(d) of the Apache License, == == Version 2.0, in this case for the Apache XmlBeans distribution. == ========================================================================= This product includes software developed by The Apache Software Foundation ( Portions of this software were originally based on the following: - software copyright (c) , BEA Systems, < Aside from contributions to the Apache XMLBeans project, this software also includes: - one or more source files from the Apache Xerces-J and Apache Axis products, Copyright (c) Apache Software Foundation - W3C XML Schema documents Copyright (c) World Wide Web Consortium (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University) - Piccolo XML Parser for Java from Copyright 2002 Yuval Oren under the terms of the Apache Software License JSR-173 Streaming API for XML from Copyright 2005 BEA under the terms of the Apache Software License

17 OSS-Lizenzen: Eclipse BIRT Project Log Quelle: Third Party Software License Link to License Rhino 1.6R1 Apache Derby NPL ١. ١ Apache ٢. ٠ Apache ٢. ٠ Xerces ٢ Java Parser ٢. ٨ Apache ٢. ٠ Apache ٢. ٠ Jakarta Commons CLI Apache ٢. ٠ JTidy R7 JTidy Project License Simple API for CSS 1.3 W3C License Flute 1.3 W3C License Commons codec1.3 Apache Axis 1.3 Prototype.js

18 Erfahrungen: Lizenzen Es ist nicht einfach, den Überblick zu behalten Lizenzierung ist relativ unproblematisch beim Einsatz in einem In-House Projekt Falls ein Produkt aus OSS-Komponenten gebaut werden soll, müssen die Lizenzen genau geprüft werden

19 Erfahrungen: Releasezyklen Teilweise hohe Kadenz an Upgrades, typischerweise nicht mit anderen Projekten abgestimmt Keine Garantie für stabile Schnittstellen Komponenten enthalten teilweise dieselben Libraries in unterschiedlichen Versionen Folge: der Werkzeugkasten muss doch gepflegt werden!

20 Releasezyklen beherrschen Behandlung von neuen Releases der Komponenten: Festhalten an einem bewährten Stand ständige Updates mit automatisierten Tests gelegentliche Updates mit manuellen Tests Kombination obiger Strategien für einzelne Komponenten ev. Einführung zusätzlicher, stabiler Schnittstellen

21 Erfahrungen: Schnittstellen Reibungen entstehen an den Schnittstellen, können aber auch dort vermieden werden Schnittstellen ermöglichen die Flexibilität des Gesamtsystems Beim Bau der Schnittstellen darf das Gesamtsystem nicht aus den Augen verloren werden Datumsformate und Umlaute sind potenziell immer problematisch

22 Erfahrungen: Benutzerfreundlichkeit Hier: Benutzer ist nicht gleich Endbenutzer, sondern technisch versierter Anwender Jede Komponente muss einzeln erlernt und beherrscht werden Relativ hohe Anzahl manueller Schritte vereinfacht Fehlersuche und bietet Eingriffsmöglichkeiten macht Gesamtprozess transparenter erhöht Fehlerpotenzial

23 Mögliche Erweiterungen Zusammenfassen der einzelnen Schritte in ein GUI (unwahrscheinlich) oder eine Sammlung von Scripten (wahrscheinlicher) Anpassung an andere Lastgeneratoren (JMeter, etc.) Weitere Tools in den "Werkzeugkasten" aufnehmen, z.b. Grinder Analyzer Start eines OpenSource Projektes für den Report-Generator

24 Schlussfolgerungen Der Einsatz mehrerer OSS-Komponenten in diesem Projekt ist ein klassisches Integrationsproblem Es geht nicht ohne Fachwissen und Erfahrung mit Integration Die Stärke der flexiblen Architektur lässt sich erst bei entsprechend aufwändigen Fragestellungen ausspielen Je nach Art des Projektes müssen OSS- Lizenzen seriös abgeklärt werden

25 Möchten Sie mehr wissen? Besuchen Sie uns am Stand 4t an der OpenExpo Schreiben Sie uns eine Besuchen Sie unsere Website oder stossen Sie mit uns an: Der OpenExpo Apéro findet im Anschluss statt