Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

11.performance meetup lasttests

1.513 visualizaciones

Publicado el

Präsentation zum Thema Lasttests auf dem 11. Performance Meetup in Hamburg

Publicado en: Tecnología
  • Sé el primero en comentar

11.performance meetup lasttests

  1. 1. 11. PerformanceMeetup28. Mai 2013Uwe.Bessle@iteratec.deEffektiver Einsatz von Lasttests zurOptimierung der Skalierbarkeit vonWeb-Sites
  2. 2. © iteratec2Agenda Erschlagen vom eigenen Erfolg Beispiele aus der jüngeren Vergangenheit Auch die Cloud ist kein Allheilmittel Fahrplan zu entspannten Live-Gängen Erfahrungen und Ergebnisse in der Praxis
  3. 3. © iteratec3Vom eigenen Erfolg erschlagenTelekom Mobilfunkseite durch iPhone5 Andrang Quelle: http://www.heise.de/mac-and-i/meldung/iPhone-Vorbestellung-ueberlastet-Telekom-1708303.html
  4. 4. © iteratec4Vom eigenen Erfolg erschlagenDaWanda : zunehmende Ausfälle durch steigende Nutzerzahlen Quelle: http://de.dawanda.com/topic/2169/10130642
  5. 5. © iteratec5Vom eigenen Erfolg erschlagenGovData: www.daten-deutschland.de vom Start weg überlastet Quelle: http://www.computerwoche.de/a/datenportal-der-bundesregierung-startet-holprig,2533210
  6. 6. © iteratec6Agenda Erschlagen vom eigenen Erfolg Beispiele aus der jüngeren Vergangenheit Auch die Cloud ist kein Allheilmittel Fahrplan zu entspannten Live-Gängen Erfahrungen und Ergebnisse in der Praxis
  7. 7. © iteratec7Erschlagen vom eigenen Erfolg Grundidee: Einsatz vonStandardkomponenten zurLastverteilung (Load-Balancer) + horizontale Skalierbarkeit derAnwendungskomponenten + dynamisches Buchenzusätzlicher Ressourcen in derCloud = Lastprobleme einfach gelöstWozu brauche ich Lasttests, ich habe doch die Cloud ?InternetFirewallLoadBalancerWeb-ServerWeb-ServerApp-ServerApp-ServerLoadBalancerApp-ServerDatenbankAuth(LDAP)Cache
  8. 8. © iteratec8Erschlagen vom eigenen ErfolgTheory meets Reality typische Bottlenecks:alles was zentral ist RZ-Anbindung, Firewall, zentraler Load-Balancer, zentraler Cache, zentrale Datenbank, zentraler AuthenticationServer (LDAP) typisches Problem:Implementierungsfehlerhebeln Skalierbarkeit ausWozu brauche ich Lasttests, ich habe doch die Cloud ?InternetFirewallLoadBalancerWeb-ServerWeb-ServerApp-ServerApp-ServerLoadBalancerApp-ServerDatenbankAuth(LDAP)Cache
  9. 9. © iteratec9Agenda Erschlagen vom eigenen Erfolg Fahrplan zu entspannten Live-Gängen Definition von Lastanforderungen Lasttests zur Überprüfung der Lastanforderungen Auswahl der passenden Tools Auswertung von Lasttests Sizing der Systeme auf Basis von Lasttestergebnissen Erfahrungen und Ergebnisse in der Praxis
  10. 10. © iteratec10FachlicheAnforderungTechnischeEntsprechungBetrachtungs-UnterschiedAnzahl Besucher #User unangemeldete BesucherVisits pro Monat #Session/hBetrachtungs-Zeitraum,Session-Timeout,Bot-SessionPageView bzw.PageImpression proTagHit/sBetrachtungs-Zeitraum,statische Ressourcen,AJAX-Requests,Tracking-Requests,API-CallsDefinition von LastanforderungenTypische Kennzahlen
  11. 11. © iteratec11 Generelle Empfehlung: Ausrichtung an den Business-Anforderungen Business-Kennzahlen als Basis für die Definition derLastanforderungen verwenden Aber: Abweichungen zur technischen Sicht berücksichtigen Die Server müssen die technisch ankommende Last verkraften Richtigen Betrachtungszeitraum wählen technisch motivierte Lastkomponenten berücksichtigen Bot-Requests Statische Ressourcen AJAX-Calls Tracking-RequestsDefinition von LastanforderungenWoran ausrichten
  12. 12. © iteratec12Definition von LastanforderungenBetrachtungs-Zeitraum : Typische Tageskurve
  13. 13. © iteratec13Definition von LastanforderungenBetrachtungs-Zeitraum : Monatsverlaufrelevante Kennzahlfür Businessplanmaßgebliches Zielfür Lasttest
  14. 14. © iteratec14 Statische Ressourcen bis zu 100 Bilder, Javascript- und CSS-Dateien pro SeitenaufrufDefinition von LastanforderungenÜbersehene Anforderungsbestandteile : Statische RessourcenMIME Type Requests▼image 80js 16html 12css 10other 6text 2flash 0 Lösungen auf CDN auslagern auf eigene Cookie-less Domain auslagern im Lasttest mit berücksichtigen (Last mit generieren)
  15. 15. © iteratec15 Woher kommen zusätzliche Requests? Google Microsoft Bing diverse andere Suchmaschinen automatisiertes Verfügbarkeits-Monitoring automatisiertes Performance-Monitoring Benchmarking der Wettbewerber Verlinkungen in sozialen Netzwerken ... Bots verursachen 50% aller Sessions 10% aller Seitenaufrufe 1-click Sessions (Bot setzt keinen Cookie)Definition von LastanforderungenÜbersehene Anforderungsbestandteile : Bot-Requests
  16. 16. © iteratec16Definition von LastanforderungenAbgestuftes Vorgehen mit mehreren Meilensteinen
  17. 17. © iteratec17 Woher kommen konkrete Anforderungen ?1. Ablösung Altsystem: Zahlen zur Nutzung des Altsystem Web-Tracking (fachliche Kennzahlen) ! Monitoring (technische Kennzahlen)Definition von LastanforderungenQuellen für Anforderungen
  18. 18. © iteratec18 Seitenverteilung aus dem Web-TrackingDefinition von LastanforderungenQuellen für Anforderungen
  19. 19. © iteratec19 Woher kommen konkrete Anforderungen ?1. Ablösung Altsystem: Zahlen zur Nutzung des Altsystem Web-Tracking (fachliche Kennzahlen) ! Monitoring (technische Kennzahlen)2. neue Anwendungen: Business Case Benchmarking (Wettbewerber)3. Interviews (Stakeholder: Fachabteilung, Betrieb, ...) haben oft nur allgemeine Ziele und wenig konkrete VorstellungenDefinition von LastanforderungenQuellen für Anforderungen
  20. 20. © iteratec20Agenda Erschlagen vom eigenen Erfolg Fahrplan zu entspannten Live-Gängen Definition von Lastanforderungen Lasttests zur Überprüfung der Lastanforderungen Auswahl der passenden Tools Auswertung von Lasttests Sizing der Systeme auf Basis von Lasttestergebnissen Erfahrungen und Ergebnisse in der Praxis
  21. 21. © iteratec211. Testarten Performance-Messung: Wie schnell ist das System ohne Last? Lasttest: Wie verhält sich das System unter Last? Stresstest: Wie kommt das System mit Überlastsituationen klar?2. Umfang Komponenten-Lasttest: Lasttest einzelner Komponenten System-Lasttest: Lasttest des Gesamtsystems3. Zielsetzungen Entwicklungs-Lasttest: Untersuchung des Lastverhaltens,Identifikation von Engpässen Abnahme-Lasttest: Überprüfung der Zielerreichung bzgl.LastanforderungenLasttests zur Überprüfung der LastanforderungenBegriffsklärung
  22. 22. © iteratec221. Testarten Performance-Messung: Wie schnell ist das System ohne Last? Lasttest: Wie verhält sich das System unter Last? Stresstest: Wie kommt das System mit Überlastsituationen klar?2. Umfang Komponenten-Lasttest: Lasttest einzelner Komponenten System-Lasttest: Lasttest des Gesamtsystems3. Zielsetzungen Entwicklungs-Lasttest: Untersuchung des Lastverhaltens,Identifikation von Engpässen Abnahme-Lasttest: Überprüfung der Zielerreichung bzgl.LastanforderungenLasttests zur Überprüfung der LastanforderungenBegriffsklärung
  23. 23. © iteratec23Lasttests zur Überprüfung der LastanforderungenTypische Anforderung : Lineare SkalierbarkeitAnzahl User
  24. 24. © iteratec24 Messung mit linear steigender LastLasttests zur Überprüfung der LastanforderungenBeispiel: Durchsatzmessung in Abhängigkeit von der Last
  25. 25. © iteratec25 Messung mit linear steigender LastLasttests zur Überprüfung der LastanforderungenBeispiel: Durchsatzmessung in Abhängigkeit von der LastLastkurve bei idealemSystemverhalten(lineare Skalierbarkeit)
  26. 26. © iteratec26 Messung mit linear steigender Last grün: linearer Bereich, Antwortzeit ist konstant,auch bei steigender Last gelb: nichtlinearer Bereich, Antwortzeiten beginnen zu steigen, orange: Sättigung, Antwortzeiten steigen synchron zur Last rot: Überlast, Antwortzeiten steigen stärker als die Last, derDurchsatz verringert sich mit weiterer Erhöhung der Last,Lasttests zur Überprüfung der LastanforderungenBeispiel: Durchsatzmessung in Abhängigkeit von der LastLastkurve bei idealemSystemverhalten(lineare Skalierbarkeit)
  27. 27. © iteratec27 Realistische Lasttests möglichst viele der Requests, die in der Realität auftauchen alle relevanten UseCases statische Ressourcen, AJAX-Calls, Tracking-Requests, … Mix der Requests (Häufigkeitsverteilung) Sessionlänge Abfolge der Requests Think-Time Datenvielfalt (Kategorien, Artikel, Suchbegriffe, Kunden, ...)Lasttests zur Überprüfung der LastanforderungenRealistische Lasttestsmodellierter Lastanteil 90% 95% 98% 99%abzubildende UseCases 5-10 10-20 25-50 50-100
  28. 28. © iteratec28 Zufällige Lasttests Deterministische Szenarien haben weniger Aussagekraft testen nur ein konkretes Szenario und verbergen Fehler finden Fehler, die in der Realität so nicht vorkommen werden zufällige Testdaten, zufällige Session-Längen, zufällige Testschritt-Reihenfolgen, zufällige Wartezeiten (Think Time), zufälligeWarenkorbgrößen Praxis Gewichtete Zufallsauswahl auf Basis relativer Häufigkeiten (CSV) Auswahl Suchbegriff aus den Top-3000 Suchbegriffen der Kunden Zufälliger Shuffle der Testschritt-Reihenfolge Think-Time zwischen TestschrittenLasttests zur Überprüfung der LastanforderungenZufällige Lasttests
  29. 29. © iteratec29 Regelmäßige Lasttests Lastziele werden nicht auf Anhieb erreicht neue Fehler machen bereits erreichtes zunichte Praxis Automatisierte Komponenten-Lasttest in der Build-Pipeline Automatisierte tgl. System-Lasttests + mehrfach individuellgestartete Lasttests am Tage Automatisierte Abnahme-Lasttest in der Release-PipelineLasttests zur Überprüfung der LastanforderungenRegelmäßige Lasttests
  30. 30. © iteratec30Lasttests zur Überprüfung der LastanforderungenEinordnung der Lasttests in die Build- und Release-Pipeline
  31. 31. © iteratec31Perfor-mance LasttestRobust-heitSystem-LPTPerfor-mance LasttestRobust-heitAbnahme-LPTLasttests zur Überprüfung der LastanforderungenEinordnung der Lasttests in die Build- und Release-PipelinePerfor-mance LasttestKomponenten-LPT
  32. 32. © iteratec32Agenda Erschlagen vom eigenen Erfolg Fahrplan zu entspannten Live-Gängen Definition von Lastanforderungen Lasttests zur Überprüfung der Lastanforderungen Auswahl der passenden Tools Auswertung von Lasttests Sizing der Systeme auf Basis von Lasttestergebnissen Erfahrungen und Ergebnisse in der Praxis
  33. 33. © iteratec33 Toolklassen synthetische http-Request-Last (ab, JMeter, Silk Performer) capture replay von realem Traffic (JMeter, Silk Performer,LoadRunner) simulierte Browser (XLT) ferngesteuerte Browser (Soke) ferngesteuerte Rechner (viele WinRunner) gesteuerte Menschengruppe TradeOff Hardware-Aufwand  Pflege-Aufwand / RealitätstreueAuswahl der passenden ToolsTool-Klassen
  34. 34. © iteratec34Auswahl der passenden ToolsHW-BedarfTool-Kategorie echteUserechteBrowsersimulierteBrowserHTTP-Traffic einfacheHTTP-Lastsynthetisch capture /replayRealitätstreue max sehrhochhoch mittel max geringPflegeaufwand min gering gering hoch mittel mittelHW-Bedarf (fürZiellast)2-5.000PC1-2.000VM50-100VM10-20 VM 3-5VMopen source Tools - •Soke •Soke •JMeter•Grinder•Gatling•ApacheBench•Siegekommerzielle Tools - •XLT •LoadRunner•SilkPerformer
  35. 35. © iteratec35Auswahl der passenden ToolsHW-BedarfTool-Kategorie echteUserechteBrowsersimulierteBrowserHTTP-Traffic einfacheHTTP-Lastsynthetisch capture /replayRealitätstreue max sehrhochhoch mittel max geringPflegeaufwand min gering gering hoch mittel mittelHW-Bedarf (fürZiellast)2-5.000PC1-2.000VM50-100VM10-20 VM 3-5VMopen source Tools - •Soke •Soke •JMeter•Grinder•Gatling•ApacheBench•Siegekommerzielle Tools -•XLT •LoadRunner•SilkPerformer
  36. 36. © iteratec36Agenda Erschlagen vom eigenen Erfolg Fahrplan zu entspannten Live-Gängen Definition von Lastanforderungen Lasttests zur Überprüfung der Lastanforderungen Auswahl der passenden Tools Auswertung von Lasttests Sizing der Systeme auf Basis von Lasttestergebnissen Erfahrungen und Ergebnisse in der Praxis
  37. 37. © iteratec37Auswertung von LasttestsÜberblick über die GesamtlandschaftPrelive-cluster50 Lastgeneratoren (8 core, 8GB RAM)jenkins-lptxltmaster-dev xltmaster-qa-166 xltmaster-qa-85LoadBalancerPA-Proxy PA-ProxyAuthOrderP13NProduct…SANLPTLoadBalancerPA-Proxy PA-ProxyAuthOrderP13NProduct…SAN LiveLoadBalancerPA-Proxy PA-ProxyAuthOrderP13NProduct…SANGraphite SplunkLoggingKPI
  38. 38. © iteratec38Auswertung von LasttestsAuswertungenPrelive-cluster50 Lastgeneratoren (8 core, 8GB RAM)jenkins-lptxltmaster-dev xltmaster-qa-166 xltmaster-qa-85LoadBalancerPA-Proxy PA-ProxyAuthOrderP13NProduct…SANLPTLoadBalancerPA-Proxy PA-ProxyAuthOrderP13NProduct…SAN LiveLoadBalancerPA-Proxy PA-ProxyAuthOrderP13NProduct…SANGraphite SplunkLoggingKPI1.XLT-Report2.Splunk-Report3.Graphite-Graph1.Antwortzeiten2.(Profiling) Log3.Ressourcen-Monitoring
  39. 39. © iteratec39 Durchsatz (Hits/s) Durchsatz  User (Laufzeitprobleme ?) Aktionen Fehleranteil Seitenladezeiten Durchsatz / Aktion Requests (Antwortzeiten, zeitlicher Verlauf) Custom Timer (Auftreten von speziellen Fehlern,Detaillaufzeiten) External Data (Externe Laufzeiten) Error and Event (Fehlerbilder, Fehlerursachen) Agents (Agent-Auslastung, Validität Messergebnisse)Auswertung von Lasttests1 XLT-Report
  40. 40. © iteratec40 Verlängerung der Laufzeiten lässt Anzahl simulierter Userüberproportional steigenAuswertung von Lasttests1 XLT-Report : Typische Fehlerbilder
  41. 41. © iteratec41 Stau auf der DatenautobahnAuswertung von Lasttests1 XLT-Report : Typische FehlerbilderErwartete Kurve
  42. 42. © iteratec42 Einbruch nach Erreichen einer Lastgrenze = ÜberlastAuswertung von Lasttests1 XLT-Report : Typische Fehlerbilder
  43. 43. © iteratec43 zunehmende Anzahl Timeouts lässt durchschnittliche Laufzeitkontinuierlich steigenAuswertung von Lasttests1 XLT-Report : Typische Fehlerbilder
  44. 44. © iteratec44Live DemoAuswertung von Lasttests1. XLT-Report
  45. 45. © iteratec45 Ziel: Fehlerbild in der Anwendung ermitteln Whitebox-Sicht Basis: Performance-Logs der Anwendung Log-Dateien aller beteiligten Maschinen werden durch Splunkeingesammelt und zentral indexiert und bereitgestellt Konsolidierung über Maschinengrenzen hinweg Konsolidierung über LogFile-Typen hinweg Dynamische AdHoc Queries möglich Explorative Untersuchung der Performance-Kennzahlen Detaillierung bis hin zum einzelnen Request Herausforderung: Zielsystem besteht aus einem Dutzend separaten Teilsystemen Welches Teilsystem ist für Performanceprobleme verantwortlich ?Auswertung von Lasttests2 Splunk-Report
  46. 46. © iteratec46RESTful Architektur1Shared Nothing alsArchitekturprinzip2VertikalerSystemschnitt3Zentrale Verantwort-lichkeit für Daten4Buy when non coreAGemeinsameBasistechnologienBMacro-ArchitekturMicro-ArchitekturShopofficeShoppagesSearch&NavigationProductPersonalisationOrderUserTrackingAuthAfterSalesELCHFrontend-IntegrationDaten-IntegrationVertikale Systemarchitektur des ZielsystemsFunktionale Gliederung
  47. 47. © iteratec47ShopofficeShoppagesSearch&Navigation(SAN)ProductPersonalisation(P13N)OrderUserTrackingAuthAfterSalesELCHFrontend-IntegrationDaten-IntegrationVertikale Systemarchitektur des ZielsystemsSeitenkomposition Der Seitenrahmen und der Hauptinhalt kommt aus dem product-System Der Miniwarenkorb liefert das order-System Die Navigation wird vom san-System bereitgestellt Die Produktempfehlungen stammen aus dem p13n-System
  48. 48. © iteratec48 Dashboard Client  Backend Request Laufzeiten Aufteilung nach PageTag Welches System ist für Laufzeitprobleme verantwortlich ?Auswertung von Lasttests2 Splunk-Report
  49. 49. © iteratec49Live-DemoAuswertung von Lasttests2 Splunk-Report
  50. 50. © iteratec50 Rubriken für Ressourcenauslastung Physikalische Systemressourcen CPU Platten-IO RAM Netzwerk-IO Logische SW-Ressourcen Plattform (Tomcat Threadpool, Java GC) Anwendung (Pools, Queues, Synchronisation nebenläufiger Threads) Verlinkung Jenkins-Job  Graphoo Dashboards Details zur Ressourcenauslastung aller Maschinen Übersichts-Dashboard zu Performance- und Lasttests Graphoo = eigene Rails-Anwendung dynamische Generierung der Dashboards mit Graphite-Grafiken Basis : aktuelles Inventory der Umgebung + Dashboard-ConfigAuswertung von Lasttests3. Graphite-Graphen
  51. 51. © iteratec51 Graphoo Dashboard mit Graphite-GrafikenAuswertung von Lasttests3. Graphite-Graphen
  52. 52. © iteratec52Live-DemoAuswertung von Lasttests3. Graphite-Graphen
  53. 53. © iteratec53Agenda Erschlagen vom eigenen Erfolg Fahrplan zu entspannten Live-Gängen Definition von Lastanforderungen Lasttests zur Überprüfung der Lastanforderungen Auswahl der passenden Tools Auswertung von Lasttests Sizing der Systeme auf Basis von Lasttestergebnissen Erfahrungen und Ergebnisse in der Praxis
  54. 54. © iteratec541. Messung der Spitzenlast im Lasttest2. Messung der Ressourcenauslastung während des Lasttests3. Messung der zugeordneten Ressourcen in der Lastumgebung4. Vorgabe der Ziellast5. Vorgabe der Ressourcenauslastung bei Ziellast Lastreserve Ausfallreserve6. Vorgaben zum Server-/VM-Zuschnitt minimale Anzahl Server/VM‘s pro Komponente Ressourcen pro Server/VM7. Extrapolation der benötigten Ressourcen in der ZielumgebungSizing der Systeme auf Basis von LasttestergebnissenVorgehen)()()()(ReRe**)()( ReRe liveTestTestliveradslastungsgssourcenauradslastungsgssourcenauLastZiellastngTestumgebulive ssourcendarfssourcenbe 
  55. 55. © iteratec55 Vorgabe Ressourcenauslastung bei Ziellast Lineare Skalierbarkeit auf einer Maschine nur bis max. 50-70%Ressourcenauslastung erreichbar Ausfallsicherheitsreserve 50% Ziel-Wert: 50% * 60% = 30% Vorgaben zum Server-/VM-Zuschnitt Ausfallsicherheit: AppServer: mindestens zwei Server pro Aufgabe MongoDB Replica-Set: mindestens 3 DBs im Replica-Verbund Ressourcen pro Server mindestens 2 core pro Server/VM (System + Applikation) nie swapping zulassen  ausreichend memory minimale disk size für sicheren Betrieb (logging, backup/restore)Sizing der Systeme auf Basis von LasttestergebnissenGrundannahmen
  56. 56. © iteratec56Agenda Erschlagen vom eigenen Erfolg Fahrplan zu entspannten Live-Gängen Erfahrungen und Ergebnisse in der Praxis
  57. 57. © iteratec57 Kontinuierliche Lasttests seit 12 Monaten 6 Ziel-Umgebungen, davon 3 für Lasttests genutzt Je Umgebung zwischen 50 und 150 VM 50 VM‘s als Lastgeneratoren 5-10 Lasttestläufe pro Tag 5-10 GByte Ergebnisdaten pro Lasttestlauf ca. 100 Metriken pro VM pro Minute ca. 100 GByte tägliches Log-Volumen aus Lasttests 3 große Meilensteine erfolgreich bewältigt Mitarbeitershop Closed Alpha Live BetaErfahrungen und Ergebnisse in der PraxisZahlen
  58. 58. © iteratec58 Ohne smarte Ziele geht es nicht. S = Spezifisch M = Messbar A = Akzeptiert R = Realistisch T = TerminiertErfahrungen und Ergebnisse in der PraxisLessons learned
  59. 59. © iteratec59 Ohne smarte Ziele geht es nicht. S = Spezifisch M = Messbar A = Akzeptiert R = Realistisch T = Terminiert Zielerreichung laufend kommunizieren und visualisieren DashboardErfahrungen und Ergebnisse in der PraxisLessons learned
  60. 60. © iteratec60 Arbeitsstand für alle sichtbar visualisieren: DashboardErfahrungen und Ergebnisse in der PraxisDashboard
  61. 61. © iteratec61 Ohne smarte Ziele geht es nicht. S = Spezifisch M = Messbar A = Akzeptiert R = Realistisch T = Terminiert Zielerreichung laufend kommunizieren und visualisieren Dashboard Die Probleme treten meist nicht dort auf, wo man sie vermutet. Lasttest so dicht wie möglich an der Wirklichkeit gestalten BlackBox TestErfahrungen und Ergebnisse in der PraxisLessons learned
  62. 62. © iteratec62erreichterDurchsatzProjektlaufzeitErfahrungen und Ergebnisse in der PraxisBeispiele für aufgedeckte SkalierbarkeitsproblemeProblem: Default-Konfiguration des nginxbeschränkt CPU-Nutzung auf einen CoreLösung: Anpassung nginx-Konfiguration
  63. 63. © iteratec63erreichterDurchsatzProjektlaufzeitErfahrungen und Ergebnisse in der PraxisBeispiele für aufgedeckte SkalierbarkeitsproblemeProblem: Auslieferung statischerRessourcen setzt App-Server unter LastLösung: Einführung Asset-Server fürstatischen Content
  64. 64. © iteratec64erreichterDurchsatzProjektlaufzeitErfahrungen und Ergebnisse in der PraxisBeispiele für aufgedeckte SkalierbarkeitsproblemeProblem: zu wenig RAM führt unter Lastzum Swapping der Such-ServerLösung: mehr RAM
  65. 65. © iteratec67 Ziele müssen allgemein akzeptiert werden SMART Zielerreichung laufend kommunizieren Dashboard Probleme meist nicht dort, wo man sie vermutet WirklichkeitsnäheEntspannte Live-Gänge in Sachen Performance- und Lastverhaltensind keine UtopieErfahrungen und Ergebnisse in der PraxisKonsequenzen für die Gestaltung der Lasttests
  66. 66. © iteratec68Eure Fragen ?Kontakt: Uwe.Bessle@iteratec.deIteratec GmbH

×