Konsten att lyckas med prestandatester

En presentation över ämnet: "Konsten att lyckas med prestandatester"— Presentationens avskrift:

1 Konsten att lyckas med prestandatester
Jan-Ove Holmqvist Arbetat med prestanda tester sedan 1995 Som konsult sedan 2000, Validate 2005 Med LoadRunner sedan 1996 Bakgrund datakommunikation och protokoll Programmering och databaser

2 Presentation Workflow (Hur lång tid tar det) Vad är Loadrunner bra på
Vad kan verktyget användas till Vilka problem kan upptäckas och hur Workflow detaljerat Vanligaste problem när du testar Vanligaste prestandaproblemen Små enkla tips

3 Workflow ny applikation / system
Systemtest Acceptanstest Start Produktionsverifiering Stopp Prestandatest Kartläggning Förberedelser Produktion Analys/Rapport Tumregel Tidsåtgång 4 veckor

4 Workflow befintlig applikation / system
Tumregel Tidsåtgång 3 veckor

5 Vad är LoadRunner bra på ?
Mäta svarstider Mäta transaktioner per tidsenhet Generera verklighetstrogna simuleringar av ”trafik” Stöd för många olika protokoll Många monitorer Analyshjälp Diagnostics j2ee, dotNet och SAP Wan-simuleringar

6 Widest Application Support
ERP/CRM SAP Oracle Siebel PeopleSoft WEB HTTP(S) XML Citrix ICA SOAP WAP MIDDLEWARE EJBs CORBA COM RMI MQSeries DATABASES Oracle MS SQLServer DB2 ODBC LEGACY 3270 5250 VT100 PROTOCOLS Clients Internet/Intranet Web Server App. Server Database Use for a LR Sale for Why LoadRunner? LoadRunner has the widest application support of any automated performance testing solution in the market. Not only do we support web solutions and ERP/CRM, but we also support all the common databases, middleware and legacy solutions out there. LoadRunner can monitor the entire system from the OS to the Network, the custom or packaged application itself and even the database. PERFORMANCE MONITORS Windows Unix Linux OPERATING SYSTEMS NETWORK SNMP WAN Emulation WEB SERVERS MS IIS iPlanet Apache APP SERVERS BEA WebLogic IBM WebSphere ATG Dynamo iPlanet App Server JAVA EJB JDBC JSP Sitraka JMonitor Databases Oracle MSSQL Server DB2

7 Transaction Breakdown Total Transaction Response time
Diagnostics Transaction Breakdown (J2EE, Oracle, Siebel) Transaction Breakdown DB Breakdown Web Server App. Server Database The Transaction Breakdown module is one of the holy grails of LoadTesting. Because it takes an end to end transaction response time and breaks it down in to the various areas the transaction time was spent. For example we can tell you exactly how much time was spent in the network, in the database and the application server. Further, within the application server, we can drill down and split the response time across EJBs, JSPs, JNDI and JDBC and down to a method level. The reason this is so valuable that previously a load tester could simply tell a developer or architect that the application was slow. Now they can pinpoint the particular method that is causing the application slowness in the context of a particular business transaction. It eliminates guesswork and accelerates time to resolution. Whenever you sell to a WebLogic or WebSphere environment, you should look to sell this additional module. Total Transaction Response time Web Server Time App Server Time Database Time JSP SWE Scripts Workflow Objects Beans Methods Connection SQL Execution

8 Vad mer kan vi använda LR till ?
Generera testdata Bakgrundslast vid funktionstester Simulera nättrafik Regressionstester Prestandatesta hårdvara och nätkomponenter Testautomation utan GUI (Enkelt GUI kommer) Till BAC (Business Availability Center)

9 Vad kan vi upptäcka med LR
Samtidighetsproblem ”Flaskhalsar” Applikationer som kraschar, stannar eller delvis slutar fungera Minnesläckor Skalbarhetsproblem

10 Kartläggning Insamling Se till att få
Krav (svarstider, samtidiga användare framtidsplaner) Funktionskarta Miljökarta test och produktionsmiljö Intervjua (utvecklare, arkitekter, driftpersonal m.fl.) Användningsfall och/eller affärsprocesser (BPT) Krav på testdata (Volymer) BAC beteenden och tider från produktion Analyser från loggbearbetning produktion Systemloggar (volymer) Se till att få Godkänd uppdragsbeskrivning (BeslutsPunkt)

11 Förberedelser Att göra Se till att
Testspecifikation och planering (förväntat utfall) Kontrollera miljö och nätverk (bandbredd loggdisk) Användarflöden (max 3 per applikation i systemet) Synkronisera klockorna på inblandade komponenter Provkör script:en (pre tester 1,10vu i minst 15min) Koda utskrifter till vu loggen och controllern (status) Verifiera monitorer Ta fram godkännande parametrar för varje körning (tex. Antal sidbyten, antal SQL, antal flöden per sekund och loggvolymer m.fl.) Se till att få godkänd testspecifikation (BP) få ”fryst” kod innan prestandatesterna börjar boka ev hjälp att monitorera delar av miljön

12 Prestanda Test Att göra under test Efter godkänd körning
Monitorera så många ingående komponenter som möjligt Kontrollera svarstider, flöden per sekund under körning Kontrollera loggar Kontrollera utfört arbete (t.ex. antal genomförda köp) Kontrollera minnesutnyttjande Efter godkänd körning Spara undan alla loggar och testen Verifiera att testen genomfördes på rätt sätt Efterarbeta tex. Accessloggar och jämför med förväntat utfall Se till att få Godkända körningar

13 Rapport Att dokumentera Att utföra Resultat av varje godkänd körning
Hur väl kraven uppfylls De resultat som kan användas som jämförande punkter nästa gång Referenser till insamlat materiel Kommentarer till avvikelser Att utföra Avrapportering av del- eller testresultat Ev. uppföljning av produktionssättning

14 Workflow ny applikation / system
Systemtest Acceptanstest Start Produktionsverifiering Stopp Prestandatest Kartläggning Förberedelser Produktion Analys/Rapport Tumregel Tidsåtgång 4 veckor

15 Vanliga problem Försök att anpassa testerna eller eliminera problemen
Överlast eller sned last För klen testmiljö Brist på testdata (både funktionellt och databas) För små volymer i systemet som ska testas Funktioner kan bara användas en gång Alla komponenter finns inte i testmiljön Beroenden till externa system Felinställda nätverksportar (full/halvduplex) Delar nätverk/servrar med andra system Kodändringar under testperioden Säkerhetslösningar och brandväggar Försök att anpassa testerna eller eliminera problemen

16 Prestandaproblem Databaser Skapar nya connections hela tiden (pool)
Använder inte bindvariabler (parsning av SQL) För små volymer i databasen Saknar index ”Glömmer bort vad jag frågade” (cache om möjligt) Full tabel scan ( inte select * from) Object to SQL mappning (mapping tools is that they provide an abstraction of the underlying database engine) MS storedprocedure ska inte börja på ”sp” (systemprocedure) Titta på ”waits”, SQL och ”connections” i databasen Använd storedprocedure för frekventa SQL:er

17 Prestandaproblem (forts.)
Nät Brandväggar (regler) Lastdelare SSLacceleratorer och contentswitchar (tappade sessioner) WebbCache:ar (gamla sidor visas)

18 Prestandaproblem (forts.)
Applikation Sessionshantering för systemet (blir utslängd) Cache mekanismer i systemet (vid uppdatering eller visar gammal information) System och applikations pooler (”Flaskhalsar”) Synkronisering i kod (”Flaskhalsar”) Inbyggda skyddsmekanismer. (dos attacker m.fl.) Minneshantering java (GC) Transaktionsmekanismer (MessageQueueing) De ger ofta långa svarstider

19 Tips Försök att efterlikna verkligheten, en användaren gör inte alltid rätt Göra fel i scripten (ex logga inte ut) Testa felsituationer i redundant miljö Fokusera test och script mot den funktion/komponent du vill testa Använd userdefined datapoint Försök att skapa ”egna” titthål (be utvecklarna att skriva ut interna poler, svarstider mm på htmlsidan. Du kan tex. skapa räknare (storedprocedure) i databasen som LR kan anropa direkt eller via en webbserver Du kan göra egna logfiler som LR kan accessa via en webbserver

20 Tips (forts.) VUgen Använd ett mallscript
Använd Zipfiler för scripten då kan du versionshantera dessa. Använd lr_vuser_status_message och lr_output_message i scripten. Använd lr_get_attrib_string för att använda parametrar ifrån runtime settings. Använd web_global_verification för tex. error felmeddelande m.fl. Använd siffror i början av transaktionsnamn för att lättare sortera dessa i flödesordning Använda VirtualTableServer (VTS), för att under körning kunna förändra vissa värden

21 Exempel från ”the real life”
En normal test av IB Ett fel upptäckt med Diagnostics

22

23

24

25

26

27 Frågor ? Ett mall script finns att få