Aufrufe
vor 1 Jahr

03 | 2016 public

  • Text
  • Urls
  • Itzbund
  • Verwaltung
  • Anforderungen
  • Entwicklung
  • Projekt
  • Restful
  • Fachverfahren
  • Projektcoach
  • Projekte
SALUS PUBLICA

Das Image des

Das Image des Unternehmens ist beschädigt. Wie konnte es dazu kommen? Was sechs Wochen zuvor geschah Die vom Testteam qualitätsgesicherte Version soll einem Last- und Performancetest 1 unterzogen werden, die Lasttestumgebung steht jedoch noch nicht bereit (neue Hardware, neue Softwareversionen, neue Versionen abhängiger Systeme, neues Deployment-Skript – es hakt an verschiedenen Stellen). Andere Projekte beschweren sich ebenfalls. Jedes Projekt hat eine bestimmte Zeitscheibe reserviert, um alleine testen zu können. Eine Verzögerung in einem Projekt verschiebt alle Termine in allen anderen Projekte. Niemand kann und will auf die Lasttests verzichten – zu Recht! Vier Wochen vorher … Eskalation: Die Lasttestumgebung steht immer noch nicht bereit. Zwei Wochen vorher … Aus verschiedenen Gründen kann das Testen erst jetzt beginnen – endlich. Erste Ergebnisse zeigen ein gravierend schlechteres Laufzeitverhalten als die Vorversion. Liegt es an der neuen Java-Version? Oder an der neuen Netzwerk-Hardware, die kurz zuvor noch installiert wurde? Oder am neuen Applicationcode? Analysen ergeben, dass manche Projekte die Terminverschiebung nicht mitbekommen und parallel getestet haben. Die Performancemessungen müssen wiederholt werden, sie haben dadurch zu viele ungültige beziehungsweise schlechte Werte produziert. Der Wiederholungslauf ist deutlich besser, zeigt aber immer noch eine Verdopplung der Antwortzeiten gegenüber dem Vorrelease. Hat wieder ein anderes Projekt durch paralleles Testen zusätzliche Last erzeugt? Oder was ist diesmal der Grund? Umfassende und zeitaufwendige Analysen werden angestoßen. Das Vertrauen in die Testumgebung ist verloren. Wenige Tage vor dem Breakdown … Die Probleme sind nicht geklärt. Zahlreiche Performanceoptimierungen wurden mit heißer Nadel gestrickt. Wirklich geholfen hat nichts. Die Anwendung ist nun zwar in bestimmten Szenarien deutlich schneller als in der Vorversion, aber die durchschnittliche Performance ist nach wie vor doppelt so schlecht wie die der Vorversion. Das Aussetzen des Releases ist nicht möglich, da die neuen Schnittstellen mit zahlreichen anderen Systemen abgesprochen wurden und alle am gleichen Tag live gehen müssen (Simultaneous Release Train). Also wird die Anwendung ausgerollt. Alle Beteiligten drücken die Daumen. Es wird schon gutgehen. Es ist bisher immer irgendwie gutgegangen. Montag, 14:15 Mit bangen Blicken verfolgt das Team den Artikel auf Spiegel Online. 1 Performance = Werden (einzelne) zeitkritische Funktionen/Anwendungsfälle schnell genug ausgeführt (zum Beispiel komplexe Suchen über verschiedene Datenbestände)? Last = Wie verhält es sich mit den Antwortzeiten bei der parallelen Anfrage/Funktionsausführung (auch von einfachen Funktionen) durch viele Benutzer? Die beiden Begriffe Lasttests und Performancetests werden in diesem Artikel teilweise synonym oder als Sammelbegriff für beide Testarten verwendet. 34 | .public 03-16 | Informationstechnologie

Profiling der Anwendung Damit die Entwickler im Falle eines Problems effizient zur Ursachenforschung eingesetzt werden können, sollten sie mit den Profiling-Tools in der Produktion beziehungsweise der Lasttestumgebung vertraut sein. Idealerweise sind dieselben Tools auch auf dem Entwicklungsrechner lauffähig. So können potenzielle Performanceprobleme frühzeitig erkannt und Optimierungen schon lokal auf dem Entwicklerrechner geprüft werden. Auch gut geschriebene Logfiles, die die Problemanalyse beschleunigen, indem sie wertvolle Informationen zum Anwendungsfall liefern, sind ausgesprochen hilfreich. Analyse von Produktionslogs Produktionslogs sollten auf Auffälligkeiten untersucht und Aufrufhäufigkeiten sowie Performanceausreißer dem Fachbereich und den Testern bekanntgemacht werden. Trends aus dem Buildserver ableiten In den meisten Projekten kommt bereits Continuous Integration zum Einsatz – eine Technik, die das Auffinden von Fehlern zeitnah ermöglicht. Diese Technik sollte um Tests, die Performanceveränderungen erkennen, erweitert werden. So kann frühzeitig und aktiv auf Veränderungen der Performance reagiert werden. Durchschnittliche Antwortzeiten werden wegen fehlender Repräsentativität wahrscheinlich kaum messbar sein, dennoch können Trends abgeleitet werden. Hierzu ist es wichtig, dass die Testumgebung sich die Ressourcen nicht mit anderen Systemen teilen muss (das heißt, keine Virtualisierung) beziehungsweise von der Performance externer Systeme nicht beeinflusst wird, sodass gemessene Werte vertrauenswürdig sind. Interessante Trends sind Anzahl Methodenaufrufe, durchschnittliche Antwortzeit aufgeteilt nach Perzentil (90 % < 100 ms, 95 % < 150 ms ...), Anzahl abgesetzter SQL-Statements, Speicherallokationen, Garbage-Collection-Häufigkeit und -Dauer sein. Erfahrung mit Frameworks aufbauen Der Sinn und Unsinn von Frameworks wurde bereits in vorherigen Artikeln besprochen. 2 Verwendet man ein Framework, verkapselt es viel Komplexität, mit der sich der Entwickler nicht mehr auseinandersetzen muss. Was dann jedoch auch „verkapselt“ ist, sind die Auswirkungen auf Last und Performance durch diese „schwergewichtigen“ Unterbauten. In Hinblick auf die Performance sollte man jedoch die Konfigurationen der Frameworks überprüfen und gegebenenfalls anpassen. Standardwerte für Framework-Konfigurationen können massive Auswirkung auf die Performance in der Produktion haben. TEST • Sicherstellen einer produktionsnahen Lasttestumgebung • Sicherstellen produktionsnaher Testdaten • Reproduzieren historischer Messwerte • Lasttestumgebung ausnutzen Sicherstellen produktionsnaher Lasttestumgebungen Bevor die Tests beginnen, sollte die Übereinstimmung der Konfiguration mit derjenigen der Produktionsumgebung sichergestellt werden. Nichts ist ärgerlicher, als nachträglich festzustellen, dass die Laufzeitumgebungen in Test und Produktion sich bezüglich der Konfiguration deutlich unterscheiden (zum Beispiel andere Software-Versionen, falsche Arbeitsspeicherzuweisung [Heap], andere Garbage-Collection-Strategie, viel zu kleiner Datenbank-Connection-Pool, zu detailliertes Logging). Sicherstellen produktionsnaher Testdaten Um möglichst reale Geschäftsvorfälle abzubilden, sollten die eingesetzten Testdaten mit der Produktion abgeglichen werden. Auf keinen Fall darf nach dem Go-Live eines Releases vergessen werden, die Lasttestdaten (Echtdaten, Anzahl und zeitliche Verteilung der Anfragen) mit denen aus der Produktion zu vergleichen und bei Differenzen die Lasttests zu überarbeiten. Reproduzieren historischer Messwerte Vor dem nächsten Release empfiehlt es sich, die Lasttestdaten mit einem Wiederholungslauf der alten Version nochmals zu verifizieren, um eine vertrauenswürdige Ausgangsbasis für die nachfolgenden Lasttests aufzubauen. Sofern eine Aktualisierung der Produktionskomponenten geplant ist, empfiehlt sich ein zweistufiger Prozess, bei dem zuerst die Hardware und dann das neue Release aktualisiert werden (oder umgekehrt). Es erleichtert die Fehleranalyse sehr, da sich immer nur ein Bestandteil im Aufbau verändert hat. Lasttestumgebung ausnutzen Über mehrere Testläufe sollten die Last- und Performancegrenzen der Anwendung ausgelotet werden. Die Simulation sollte die Lastverteilung mit Lastspitzen, gleichzeitige Zugriffe externer Systeme und parallel dazu ausgeführte Batches über einen längeren Zeitraum einschließen, um anhaltende Performanceverschlechterungen nach Stressphasen und bei Speicherlecks feststellen zu können. 2 .public Ausgabe 01-2015 und 02-2015 Informationstechnologie | .public 03-16 | 35

msg

01 | 2018 public
02 | 2017 public
01 | 2017 public
02 | 2016 public
01 | 2016 public
02 | 2015 public
01 | 2015 public
01 | 2014 public
01 | 2014 msg systems study
01 | 2015 msg systems Studienband
Future Utility 2030
Lünendonk® Trendstudie
Digitale Transformation | DE
Digital Transformation | EN
DE | inscom 2014 Report
EN | inscom 2014 Report

msgGillardon

02 | 2018 NEWS
03 | 2016 NEWS
02 | 2016 NEWS
01 | 2016 NEWS
03 | 2015 NEWS
02 | 2015 NEWS
01 | 2015 NEWS
02 | 2014 NEWS
01 | 2014 NEWS
02 | 2013 NEWS
01 | 2012 NEWS
02 | 2011 NEWS
01 | 2010 NEWS
MaRisk
01 | 2017 banking insight
01 | 2015 banking insight
01 | 2014 banking insight
01 | 2013 banking insight
01 | 2012 banking insight
02 | 2011 banking insight
01 | 2011 banking insight
01 | 2010 banking insight
2018 | Seminarkatalog | Finanzen

Über msg



msg ist eine unabhängige, international agierende Unternehmensgruppe mit weltweit mehr als 6.000 Mitarbeitern. Sie bietet ein ganzheitliches Leistungsspektrum aus einfallsreicher strategischer Beratung und intelligenten, nachhaltig wertschöpfenden IT-Lösungen für die Branchen Automotive, Banking, Food, Insurance, Life Science & Healthcare, Public Sector, Telecommunications, Travel & Logistics sowie Utilities und hat in über 35 Jahren einen ausgezeichneten Ruf als Branchenspezialist erworben.

Die Bandbreite unterschiedlicher Branchen- und Themenschwerpunkte decken im Unternehmensverbund eigenständige Gesellschaften ab: Dabei bildet die msg systems ag den zentralen Kern der Unternehmensgruppe und arbeitet mit den Gesellschaften fachlich und organisatorisch eng zusammen. So werden die Kompetenzen, Erfahrungen und das Know-how aller Mitglieder zu einem ganzheitlichen Lösungsportfolio mit messbarem Mehrwert für die Kunden gebündelt. msg nimmt im Ranking der IT-Beratungs- und Systemintegrationsunternehmen in Deutschland Platz 7 ein.


© 2018 by msg systems ag - powered by yumpu Datenschutz | Impressum