Presentation laddar. Vänta.

Presentation laddar. Vänta.

Jan-Ove Holmqvist 08-5900 45 88 Arbetat med prestanda tester sedan 1995 Som konsult sedan 2000, Validate 2005 Med LoadRunner sedan 1996.

Liknande presentationer


En presentation över ämnet: "Jan-Ove Holmqvist 08-5900 45 88 Arbetat med prestanda tester sedan 1995 Som konsult sedan 2000, Validate 2005 Med LoadRunner sedan 1996."— Presentationens avskrift:

1 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 Konsten att lyckas med prestandatester

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 Produktion StartStart Stopp Prestanda test KartläggningFörberedelser Analys Åtgärd Test Tumregel Tidsåtgång 4 veckor Analys/ Rapport SystemtestAcceptanstest Produktionsverifiering

4 Kartläggning Förberedelser Prestanda Test Analys Uppföljning 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 PROTOCOLS PERFORMANCE MONITORS 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 Databases •Oracle •MSSQL Server •DB2 JAVA •EJB •JDBC •JSP •Sitraka JMonitor APP SERVERS •BEA WebLogic •IBM WebSphere •ATG Dynamo •iPlanet App Server WEB SERVERS •MS IIS •iPlanet •Apache NETWORK •SNMP •WAN Emulation •Windows •Unix •Linux OPERATING SYSTEMS Web ServerApp. ServerDatabaseInternet/IntranetClients

7 Diagnostics Transaction Breakdown (J2EE, Oracle, Siebel) Web ServerApp. ServerDatabase Transaction BreakdownDB Breakdown Web Server Time App Server Time •Scripts •Workflow •Objects •Beans •Methods Database Time •Connection •SQL Execution Total Transaction Response time •JSP •SWE

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 • 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 Att göra • 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 Förberedelser

12 Prestanda Test Att göra under test • 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 • 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 Produktion StartStart Stopp Prestanda test KartläggningFörberedelser Analys Åtgärd Test Tumregel Tidsåtgång 4 veckor Analys/ Rapport SystemtestAcceptanstest Produktionsverifiering

15 Vanliga problem • Ö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) Databaser • 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å


Ladda ner ppt "Jan-Ove Holmqvist 08-5900 45 88 Arbetat med prestanda tester sedan 1995 Som konsult sedan 2000, Validate 2005 Med LoadRunner sedan 1996."

Liknande presentationer


Google-annonser