"Software-Performance immer wichtiger"

Bernd Greifeneder gründete 2005 das Linzer Software-Unternehmen dynaTrace. Im März 2009 machte Gartner dynaTrace zum 'Cool Vendor for IT Operations'. Gegenüber silicon.de gibt Greifeneder darüber Auskunft, wie die Software-Performance und das Web 2.0 zusammenhängen und welche Pläne er mit dynaTrace hat.

Greifeneder leitet als CTO den Bereich Forschung und Entwicklung von dynaTrace. Davor war er CTO bei Segue Software, das mittlerweile zu Borland gehört. Unter seiner Leitung wurden Produkte wie 'SilkPerformer Web Load Testing' und 'SilkCentral Performance Manager' entwickelt. Greifeneder studierte an der Johannes-Kepler-Universität Linz Informatik und Mechatronik.

silicon.de: Bevor Sie 2005 in Linz dynaTrace gründeten, waren Sie CTO bei Segue Software. Warum haben Sie Segue damals verlassen?

Greifeneder: Ich hatte bei Segue mit vielen Kunden zu tun, die unsere damaligen Produkte zum Lasttesten und synthetischen Transaktionsmonitoring eingesetzt haben. Aber die damit erkannten Performanz- und Skalierbarkeitsprobleme konnten nur mit großem Aufwand behoben werden. Das hat mich dazu motiviert, nach einem Produkt am Markt zu suchen, welches für mich als CTO und Softwarearchitekt, aber auch für den Einsatz im Test- und Produktivbetrieb geeignet ist.

Bernd Greifeneder
Bild: dynaTrace

Da ich eine solche Software-Lösung nicht finden konnte und ich bereits eine sehr konkrete Vision des Software-Applikation-Lifecycle-Ansatzes hatte, entschloss ich mich, eine eigene Firma zu gründen, um diese Vision in die Realität umzusetzen. Neue Ideen brauchen ein neues Fundament.

silicon.de: Wie andere Anbieter im Application-Performance-Management-Markt (APM) behaupten Sie, die Ursachen der Performance-Probleme von Java-und .NET-Anwendungen aufdecken zu können. Was machen Sie anders als Ihre Mitbewerber?

Greifeneder: Richtig, einige Mitbewerber können Performance-Probleme aufdecken. Aber sie können weder die problematische Transaktion automatisch aufzeichnen, noch liefern sie tiefgehende Root-Cause-Informationen zur betroffenen Transaktion mit Kontext-Informationen bis hinunter auf die Codezeile. Der Grund dafür liegt darin, dass die Mitbewerber im 24x7-Betrieb ausschließlich mit statistischen Samples messen. Damit geht die Performanzmessung einer 'bad transaction' im Durschnittmix der Samples unter. Unsere Performanzanalyse-Algorithmen arbeiten bewusst nicht auf statistischen Heuristiken, sondern auf akkurater Analyse von allen Einzeltransaktionen. Damit untersuchen wir das Verhalten der Transaktionen und nicht der statistischen Symptome.